There’s a brief README.txt in the zipped archive linked above, but the theme’s main features are:

• XHTML compatible (in core theme files)
• Minimal, semantic markup
• No sidebar
• Excerpts on archive and category pages
• Implicit RSS feeds: the only orange icon is in your browser chrome
• Adaptive top navigation
• Separate pages for archives, categorisation and blogrolls
• Next/previous rel links in header
• Support for special pages e.g. blogroll, tag cloud

The todo list includes:

• Implement my Blogthis! plugin, while trying to keep minimalist
• Unobtrusive hiding of elements, using jQuery
• Improve styling

The theme is in a fairly alpha state. The PHP is fairly straightforward, apart from some neat theme functions, but don’t blame me if everything goes bang.

Alsa seems stable and graphics support is present from installation onwards. Enabling fancier 3D compiz effects requires the nvidia-glx-new package; compiz spots this, however and prompts for installation. All very smooth. Wireless works; my VoIP headset works; but I haven’t yet tested Bluetooth.

The only problem was in upgrading from Gutsy: my previous peregrinations had rendered my hybrid distribution shafted and incapable of upgrade. This isn’t a problem, though, if one has installed the /home directory (and in my case the /music one too) on a separate partition: the Ubuntu Live CD will blat the root partition with Heron, but leave the other partitions alone if you so require. Don’t resize any of your partitions during installation, though, or you’ll lose everything. Everything!

It’s called Straight Edge, and I’ve switched to it today. Once I’ve finished alpha-testing it I’ll write more about it, and offer it for download if anyone’s interested.

Otherwise, it all seems to be running very smoothly. Do let me know if you see anything crazy. I hope to upgrade more frequently in future, as it was a far better experience than I’d expected.

It was clear after the first half hour or so that there were going to be far more people there than Rob had expected: I think in the end there were around 50 to 60 attendees. A brief, slightly confusing “speed-dating” session later, I also realised that there was a real cross-section of Drupal fans there. There were freelance theme developers, module coders, hardcore sysadmins, CSSers, end users, tech writers, Drupal beginners…. A well-rounded audience, that hopefully stopped the meeting being too focussed on one layer of the CMS.

The talk from Tracy Frauzel at Greenpeace, about their experience with Drupal, was really enlightening, as was the phoned-in discussion from Joel Bassuk of Oxfam International (new site going live, 3–4 weeks’ time). It’s good to hear of people enjoying their transition from other systems to Drupal (even if the imports tend—like all data imports—to be occasionally painful).

It was also interesting to see how far people would tend to go with contributed modules, tweaking the theme and hammering away at the admin config, rather than building their own modules or (shudder) hacking core. Oxfam’s experience with forking Plone shows the perils of hacking core; to avoid doing that in Drupal, Greenpeace had used the usual locale hack to translate core strings to their liking (I say “usual”: I hadn’t seen it in the wild before, so again it was nice to hear a success story).

I really look forward to where Drupal for NGOs will go from here—maybe collaborative/accretive online conversations and resources, but most importantly the next event. This one was a really smooth first event, and it bodes well for future ones. From my experiences with the OGNs, I’ve learnt that organizing a fairly straightforward event can be incredibly stressful, and when it all works perfectly then nobody notices all the effort you’re making: that’s sort of the point of the effort, but it’s incredibly infuriating that people think you’re kicking back and feeling chilled! All the contributors, everyone who spoke or who volunteered some information, contributed to a great evening. Cheers, everyone.

That works just fine for most purposes, but we may have to bring in content from not just outside the core Drupal tables but outside the core database, and even on a remote server through webservices. To this end we’ve decomposed the core user module’s user_load() and user_save() functions. This helps us understand better both the workflow and at what points in it our own code can motor into life, query all those extra resources (or set those queries in motion), assemble the rest of the user++ object, and then hand control back over to Drupal.

For those who don’t know much about Drupal, its core has a hook-based API structure. At certain points in its workflow, it checks all the modules for functions following certain naming conventions (typically the module name followed by the hook name e.g. mymodule_init on response startup, or mymodule_block to return details about the module’s support for Drupal page furniture). Any matching hook functions are called in the order defined by module weightings, and then page processing will generally continue: you can crowbar a grind-to-a-halt exit() in your hook, but it’d be unwise, as you can never be sure what tidying up Drupal might need to do after your hook. Outside these hooks, your code has little control over Drupal’s core functioning, unless you stub out entirely the bits of core you need yourself, and get your request to use those bits instead.z

Because of the way they let your code tag along with Drupal’s powerful core, hooks are essential to developing modules in the most Drupalish way. With that in mind, here are flow diagrams of the three basic aspects of user functionality—create new, load, save existing—lifted straight from examination of the code:

• Loading an existing user with user_load
• Creating a user: saving a new user with user_save
• Updating a user: saving an existing user with user_save

Although you have to save a user before you can load them, I’ve put this functionality first in the above (admittedly unordered) list. There are two main reasons for this:

1. user_save actually calls user_load a number of times, once or twice, to “refresh” the user object
2. user_load is a more primitive function and so bears examination first

Stripped down, user_load consists of: querying the database for a core user record matching the search criteria; returning this and the extended profile data; unserializing a free-data field and inserting it into the user object; discovering user roles; triggering hook_user('load') and returning the object (or boolean false, if no user found).

What this reveals (which I didn’t realise before) is that the anonymous user is in the Drupal users table, with ID=0. Otherwise, searching for this user would return no records, and the anonymous user object could not be instantiated. You could therefore attach rich data to the anonymous user, if you were in a hacky mood.

The two user_save workflows are fairly similar. Creating a user means obtaining an ID from the database: because some MySQL providers have poorer feature sets than others, referential integrity is ensured at the application level rather than the database level. In place of obtaining an ID, user update calls hook_user('update') to pre-process the user. Both workflows then set aside special fields, such as the user’s password, user roles and any profile fields managed by that module (determined from user_fields()). Then they save this data into the database in slightly different orders, with user creation calling hook_user('insert') early on, and the update procedure calling hook_user('after_update') much later in the process, just before determining the external authentication mappings (e.g. OpenID) and returning the user object.

What does this mean for us? Well, we’ll want varying amounts of data to piggyback on the core user object, so we have somewhere to cache it. Ideally this data won’t be summoned—brought out of the distributed data ‘cloud’—on every request/response cycle, so we’ll need to do some local cacheing, but not so much that we’ll get out of synch with the cloud (or that we’ll duplicate sensitive data). We think that, given the pair of hooks in user_save for existing users, we’ll have just enough leverage to do this: the first hook will effectively “tear down” our extra data, so we can do what we want with it, and store it somewhere temporarily; the second hook will “set up” the user for the rest of the request, by putting all that data back in. The existence of user_load within user_save complicates things somewhat, but at the same time it gives us some more wiggle room, because each call to that function fires another hook.

A Drupal hook is worth a thousand lines of module code, but they’re still a bit few and far between for some workflows. Hopefully the accompanying images will help anyone reading to find them, and ditch those thousand lines before they’re even written.

First, a bit of background. Postcode Anywhere provides a per-lookup paid webservice, converting UK postcodes into valid house names/numbers, streets, towns etc. It allows you to accept a user’s submission of a postcode to e.g. a signup form, then present them with a list of sample addresses, rather than them having to fill in all of their address details.

There’s only really one method exposed for the PA functionality, and it takes a text postcode and returns an array of results:

$data = pamb_pa_get_bypostcode($postcode);

MailBuild and CreateSend, on the other hand, provide a way to store email lists and send newsletter campaigns to subscribers. However, our client also wanted to use it to store snail-mail addresses, so they could use it for both requests for printed matter and also to keep subscribers up to date via email. It was possible to implement this using custom fields, of which the service permits around a dozen: address line 1, address line 2 etc.

There’s an existing Mailbuild module, which technically does the trick, but it’s overkill compared to what the client wanted. pamb’s integration is essentially just “push”: it passes the results of a form submission to CreateSend, by using a template (the one you’ve moved to your theme directory) to “theme” the data as an XML packet. If there are no problems then the system returns nothing; otherwise, it returns a structure of data including the HTTP response and the SOAP packet from the request.

Here’s some sample code:

/* Send SOAP packet */
$no_probs = pamb_mb_send_soap($form_id, $form_values);

/* If OK, set a generic message and redirect: the redirect will pick up
on the generic message and know all has gone well */
if(!isset($no_probs)) {
  drupal_set_message(t(AUTO_SUCCESS));
}

/* If not OK, $no_probs contains the diagnostics */
else {
  /* do something else */
  drupal_set_message(t(AUTO_ERROR));
}

For now, for want of a better name, the module is called “pamb.” And [edit] the code is now available on Sourceforge under the GPL: that should make it compatible with Drupal’s core licence.

1. Download pamb: currently only available in subversion, but clients exist for Linux, Windows and OSX.
2. Unpack it into your modules directory
3. Edit the defines at the top of the file for your own Postcode Anywhere or MailBuild/CreateSend accounts.
4. Stick the pamb_soap.tpl.php in your theme directory
5. Switch on the module in the admin interface

You’re now ready to start developing with its handful of functions. Feedback more than welcome, as given Drupal’s minimal support for mailing-list functionality in core it’d be good to make this into a fully-functional module for similar third-party contact services, and even port it to 6.x.

[edit 2008-06-17: now hosted on Sourceforge]

[Edit: run Python using Javascript too.]

“IDEs are draining users away, but it’s not the classic fat-client IDEs that are ultimately going to kill Emacs. It’s the browsers. They have all the power of a fat-client platform and all the flexibility of a dynamic system. I said earlier that Firefox wants to be Emacs. It should be obvious that Emacs also wants to be Firefox…

“… [N]ow the browsers are starting to sprout desktop-quality apps and productivity tools. It won’t be long, I think, before the best Java development environment on the planet is written in JavaScript.”

I’m more of a vi user these days—it behaves much more consistently over emergency ssh sessions—but as a general advocate of Emacs over IDEs I can see his point. Browsers should want to be like Emacs, or at any rate more like the VM of your choice.

Between browser-as-VM, Firefox, ECMAScript and compatibility frameworks there’s the seeds of an RIA revolution. After all, to what extent will industries gladly rest their financial weight on RIAs, so long as they’re all written in Flash-on-the-browser, and so long as browsers remain so unpredictable and Flash remains… well, Flash?