Andy Chase

I worked through the day’s beastly heat (upper 80’s and humid, not normal weather for early May in New England) and am pleased to announce the launch of jeffmenzies.com, built in Drupal 6 with a custom subtheme based on Interactive Media.

While some work had already been done on the site before this weekend, I would say that about 80% of it was done in the last 36 hours. This is partly due to the power of Drupal’s theme layer, the Drush module, and of course Views and CCK… but I realized that it was also due to the fact that the parameters were refreshingly simple. Now that we’ve gotten used to the ability to slice and dice content in nearly any way imaginable, we have a tendency to overdo it… we try to cram too much information on home pages, and we overstructure content that lives underneath, creating elaborate tagging mechanisms and cross-linked views and meticulously formatted archives, timestamps, bylines, and profiles… often just because we can. I know I haven’t forgotten what it was like to get a static HTML site like this 90% built, only to decide that a font color or some aspect of the layout needed changing; lots of find-and-replace, save, upload via FTP, reload, lather, rinse, repeat. It was miserable, and that was before you even got into working on actual content, which led to its own open-edit-save-upload-reload cycle.

So yes, it’s very tempting to go crazy with multiple meticulous views of your data, because tools like Drupal make it so damn easy. By contrast, this site was a very enjoyable exercise in minimalism, and a useful reminder that in many cases, less can be more.

It’s 2010, nearly two years after the release of Drupal 6, yet there are still sites out there using Drupal 5. (We can’t all always be on the bleeding edge.) As time goes on, troubleshooting obscure problems gets harder and harder as new versions of old modules are released and discussed… so for those of you fighting the good fight to support a Drupal 5 project, here’s how I fixed some weirdness that I experienced with Drupal 5 CCK fieldgroups.

The problem I was having was that some grouped fields weren’t being themed with the standard <fieldset> tag wrapper when viewing (not editing) the nodes they belonged to.

I spent some time digging through my custom code, wondering what I might have done at the theme layer or in a hook_form_alter() to cause this weird, inconsistent behavior. I couldn’t find anything.

In a final act of headscratchery, I went back to the CCK ‘Display Fields’ form, where you can customize how your fields and fieldgroups get formatted when a node gets rendered for display. Everything looked normal, but just for the hell of it I switched the styling setting from ‘fieldset’ to ‘simple’ - that worked just fine. I then switched it back to ‘fieldset’, and re-saved. Suddenly the expected fieldset formatting kicked in for those misbehaving fields; I’m assuming there is a cache somewhere that simply needed clearing, and resubmitting the ‘Display Fields’ form did the trick.

Last night I decided to get more familiar with CCK and Views integration by way of rebuilding the Chords module, which is functional in its current state but doesn’t do much.

So, I’ve begun work on Chords 2 for Drupal 6. Major architectural changes:

• The original module has been split into two:
  • The Chords API module provides basic functionality around calculating and rendering chords (and keeps the original module namespace)
  • The Chords UI module contains the simple chord builder tool from the original module.
  • New modules are on the way:
  • A Chords Field module will provide a new CCK Chord field and some useful formatters
  • A Chords Views module may provide Views 2 integration, if Chords Field doesn’t cover it.

I know better than to state a timetable, as these things have a way of languishing when other shiny objects catch my interest. However, if you’re interested in playing with the latest and greatest code, check out the CVS HEAD.

If you haven’t listened to Lullabot Podcast No. 75 yet, go check it out. It’s an excellent discussion around the problem of how to distribute the cool and interesting things you’ve built with Drupal in a reusable way, or in such a way that those features can be bolted on to an existing web site.

I am not really involved at all with the day to day development of Drupal or debates over its future, but from some of the issues discussed on the podcast and some of the debates over UI I heard at Drupalcon DC, it seems like there’s a fundamential tension growing over whether Drupal is the web application itself, or just a set of APIs upon which you can build great web applications (and which happens to have a built-in CMS that you can’t turn off.)

In terms of reusable features, the current response you get when asking “Hey, is there a module to do X in Drupal?” is usually along the lines of, “Sure. You just have to install the Frobnosticator module, then create a Foo Profile with the Potrezebie module and configure a workflow so that the Fonebone action gets triggered by foo_nodeapi blah blah blah. It’s easy!”

The problem is that it’s not really easy if you’re not familiar with any of the modules involved in the recipe. Often times it seems like you spend so much time on the configuration and interaction of modules to achieve something only partially resembling the functionality you had in mind that you might have been better off writing a module from scratch that does exactly what you want, without the clunky overhead of half a dozen modules all sort of working together.

I’ll be following Features/Install Profiles/Distributions discussions with interest.

Drupal 5.x does not support HTML image inputs (<image type="input" src="…"/>) out of the box. A common solution to this limitation is to provide your own theming function to handle any buttons you want to turn into images, as described at http://drupal.org/node/144758.

read more

The Drupal Form API is a wonderful thing… once you’ve been using it long enough, it’s easy to forget all of the laborious validation and post-submit processing you used to do by hand for each and every HTML form in your solution.

The FAPI does things its own way, though, and if you’re building especially complex forms that involve multiple steps or dynamically generated options, you may encounter the following error upon submitting your form:

read more

If you’re wondering where the color picker on your Drupal theme settings page went, ask yourself: Did you change the ‘files’ access mode from ‘Public’ to ‘Private’? According to http://drupal.org/node/92059 that makes the color picker go away.

I’ve been tinkering with Drupal 5.1 in one capacity or another for the last 2 or 3 months, but by and large it’s been from an on-and-off, complete-newbie perspective; install some modules, click around, add some lorem ipsum content, and wonder if you did it right.

I have spent some time learning about module development, but not knowing enough about the “right” way to do things, even the successes I’ve had there feel like a bit of a question mark.

When it comes to programming problem-solving, I usually do pretty well thanks to the internet; you can find an explanation and/or example of darn near anything if you choose your search terms carefully.

That’s usually all I need; it might take me a while to absorb whatever new technique or classes/functions I’m using, but the path is usually clear.

I’ve finally started getting my hands dirty with Drupal over the last couple of weeks, going through the process of actually building a site versus adding a couple of pages and menu links here and there to see how it works, and now poking around under the hood to learn how to extend it.

Adding a bunch of pages in a row using the standard interface is usually a pain in any CMS, and Drupal is no exception: Click to expand all of the option fields, click through another screen to attach the new page to a menu, try and remember the weight of the last item you added, repeat.

Half the problem when trying to learn a new language or platform on your own is finding a practical application for it. You never get very far with “Hello, World”.

I’m really surprised there are no Drupal modules out there facilitating the import of existing content and/or menu structures. At least, none that I have been able to find other than the excellent WordPress Migration Utility . I used that to move the last 5 1/2 years’ worth of blog entries over to Drupal.

So, there’s my first practical application: a module that imports either a page hierarchy, creating a menu and stub Page nodes, or possibly even importing actual content.

I’m not sure what the import format will be. The smart way to develop this would be to make the import tool pluggable, so other people could write drivers to import whatever format they need. I think that’s overly ambitious for the first version of this plugin, but I’m beginning to get a sense of how that could be accomplished without too much trouble in Drupal.

31 January, 2009 It took me a while, but I did ultimately build just such a module. It’s in the Drupal contributions repository, and it’s called Bones.