Starbow Consulting

Here is a screencast showing off two modules that I have built on top of the Popups API module. They are Popups: Add & Reference, which allows the Node Reference widget to create new nodes, and Popups: Subedit, which allows semi-in-place editing of just parts of a node.

This demo starts with a fresh Drupal 6 install, with the Popups modules, CCK, Node Reference and Admin Menu enabled.

View it full size. You might need to turn up your volume, the sound is a little low.

It is time to review my personal module release tagging strategy. The available tags have changed since I started releasing Drupal modules, and my understanding of the flow has evolved recently. Readers will understand this better if they are familiar with the info on the Drupal contrib branches and tags page.

Here is my current thinking (replace X with an increasing counter starting with 1):

I have been meaning to get up a good Popups API article forever and a day. It has changed a lot since the last time I blogged about it. Fortunately sirkitree just kicked out a great article Popups addiction. sirkitree has been making some solid contribution in the popups issue queue, and I got a chance to meet him at the last SF Drupal Users Group. He told me about what he and his gang have been doing with Popups over at ParentsClick Network.

I gave a presentation on Panels 2 at the January Berkeley Drupal Users group. We got a lively discussion going, and Chris from Gravitek Labs demoed some sites they have been working on that leverage Panels.

People have been talking about John Van Dyke's Actions module ever since I started up with Drupal, back in the 4.6 days. It is now baked into Drupal 6, and all this time I have been kind of wondering what the fuss was about. Now, with my discovery of "Views Bulk Operations":http://drupal.org/project/views_bulk_operations I finally have a reason to get excited about actions.

A screencast demoing the Popups API enabled block admin page. This shows off the Popups API and Popups: Administration modules.

Doing a good wiki in Drupal 6 is surprisingly hard. My project to create a site with MediaWiki-like functionality for climate research at UC Berkeley took much longer than I thought it would, and the result was mediocre. Here are my notes evaluating different modules:

The Drupal markup filtering system is confusing for a couple of reasons:

• The terms “format” and “filter” are used inconsistently. For example, the main admin page is title “Input formats”, but the url is “admin/settings/filters”. The best I can do is: The markup filter system consists of multiple input formats which are ordered stacks of individual filters.
• The term “Input format” itself is misleading, because the filters work on output, not input.

• The “Input format” admin page is unhelpful and hard to navigate.

Here is a use case that happens to me all the time, and I am boggled that I haven’t found a simpler solution. I have a bunch of Faculty nodes, and I want to specify that some of them belong to various Committees. I want a committees page that has a linked listing of committees, and then each committees page should have a description of the committee and a linked list of all the members. Also it needs to be dead simple for a non-skilled content editor to edit the committee descriptions and to create new faculty without needing to create all the committees ahead of time.

You can do almost all of this with Taxonomy free tagging and Views 2, but the easily editable per-committee description trips you up. For that you need a node type with a Reverse Node Reference. I am open to suggestions, but here is how I do it:

I am really loving the improvements to subthemes in Drupal 6. They took what was an interesting idea in Drupal 5 and made it even more powerful and much easier to use. I have been finding a lot of power rolling out a sets of websites, using subsubthemes.

Theme X: Free theme downloaded from drupal.org
Theme Y: My modifications to that theme, as a subtheme of Theme X. I want these mods to apply to all my subsubthemes. base_theme = Theme X
Themes A, B, & C: The actual themes used on my sites. base_theme = Theme Y

The great thing about this setup is that I can continue to install updates to Theme X, with minimal disruption to my actual sites' themes. There was one problem though: