I had a fun afternoon a few months back when all the imagecache images broke on a site I'd just taken live. I've just figured it out, so I'm telling you about it.

This was the situation:

• subsite.client.com was where I was developing the site, one of a family of multisites.
• subsite.com was a parked domain that went to just this site. It was this I'd just pointed to the IP of the box and that wasn't showing any images.

On the development domain, all worked fine. On the subsite domain, nothing.

I've spent the last few days wrestling with an evil bug. I had a content type, called Card, which I could create fine when logged in as any authenticated user of any role. All cool. I should also be able to create this content as anonymous.

Indeed, going to Create Card (node/add/card) was fine. I got the form, filled it in, but then nothing. Page Not Found where the created node was expected. The node simply wasn't created! But there were no warnings or errors. Big fat nada.

So I've been having lots of fun (read: horrible pain) this week thanks to some quirks of Drupal that only really present themselves when you are looping through, loading, saving and manipulating nodes quickly. The scenario for this sort of thing is normally (yup, you've probably guessed it) importing.

First, a note on "compatibility" (for want of a better word). This piece is written after some extensive theming work in Ubercart 5.x-1.7. Much of this is still useful information for the Drupal 6.x version of Ubercart, but it may not be wholly accurate.

I should also note that this is not really a hand-holding step-by-step piece. It's more for people who are already pretty familiar with theming Drupal and just want to know where to look.

There is an issue with the Drupal Forms API in Drupal 5.x. It assumes there is one form on a page so it does not handle duplicate form IDs very well (read, at all!) - as such, if your forms are loaded in blocks or you just drupal_get_form() to load extra forms on a page in Drupal 5.x, you might well find yourself with several submit buttons all with an ID of id="edit-submit". Which sucks!

So you've got a client who wants to have a Drupal form send something off to another website. In my case my client wanted to manage their newsletter from the SalesForce CRM (which they doubtless paid gazillions of dollars for, so they'd better bloody well use it, etc.) so newsletter sign-ups needed directing there.

This is a quick HOWTO on altering the core Search module's database query in Drupal 5.x and 6.x. I think this will be different in 7.x, as there seem to be new, better hooks for manipulating queries, but we're not there yet.

For now, the hook you need is hook_db_rewrite_sql(). This allows you to add JOINs and WHERE clauses to existing SQL queries being generated by other Drupal modules.

You probably know about dependencies in modules and how to declare them in a module's .info file. In case you're not familiar with the concept, it looks like this:

(Slightly different in Drupal 5.x - be warned!)

Each one of those modules must be enabled before Drupal will allow you to enable the module you want to install. Neat, huh? But there is a problem:

I'm in the process of updating my training materials for various Drupal courses I teach so they reflect the new Drupal landscape, post Drupal 6 launch and wide acceptance. One of the interesting things is the number of killer modules in Drupal 5 that have died (either the maintainer lost interest, ran out of time or found a Drupal 6 module that does the same job better).

Chris Charabaruk, AKA @coldacid, is leading the charge to replicate Dan Zarella's Tweetbacks for Wordpress in Drupal. I'm hoping to help him out, as WhatTalent are interested in the module for a start. And so am I! =)

Take a look at the initial dev snapshot here:
http://drupal.org/project/tweetbacks

It's marked as Drupal 5.x, but alter the info file and it should be fine for Drupal 6.x as well.