6.x

I am now batting nodes, complete with imagefield, between separate instances of Drupal with merriment and glee. For yes, I do have a working beta of Content distribution.

I'm about to quickly write a service to get CCK's content_fields() array from the remote, distributing site, so that the retrieving site can show a UI of possible values for a Views nodereference argument. Try it. It all makes sense once you do.

But I remember a couple of months ago, when Services was a total mystery to me. I installed it, knowing that this was what I needed to achieve this task, but I was baffled by it. What was a Service? And how come I needed a server as well? Surely a service is a kind of server? Argh! And so on.

The penny dropped a few weeks ago, when I suddenly realized that a service is really just another kind of hook_menu() item.

Consider: in hook_menu(), you define which function Drupal should call when it gets an HTTP request at a certain path, say, 'node/1'. And in hook_service(), you define which function Drupal should call when it gets a service method request, in this case via XMLRPC (which is still black magic to me, but with Services module, I don't need to know, because it Just Works). For that matter, in Drush's hook_drush_command(), you define... etc etc. They are all the same!

This has me wondering whether for Drupal 8 we should abstract this out to a general hook_callback(), where we define what function Drupal should call when it receives any kind of external input.

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.

The problem is that if you go to admin/settings/file-system you get a different thing depending on the domain! Each time, you get 'sites/CURRENT_DOMAIN/files', and the reason is this function:

So if the files directory has not been explicitly set and you're just relying on defaults, you're getting the wrong one.

I don't follow the internal workings of the file system or imagecache (or even symlinks which I consider dark magic on the commandline) to know if this breaking of imagecache is a bug or not.

But at least this is a ten-second fix on future sites. You'll find me here reading this post when I next have to set one up.

I've been putting off setting up multisite on my localhost for ages, mostly because in the past I've found getting Apache virtual hosts to work can be a bit tricky: not impossible, but the sort of thing where I could easily lose an hour on a minor thing I've forgotten to do. And after all, with a shiny new iMac and a hard drive whose proportions I can't even remember, why not just 'drush dl' all over again?

But I'm actually working on a multisite project at the moment, and suddenly getting this to work becomes more interesting than having another SVN copy of my code kicking around.

Given multisite can respond to subfolders, I was wondering if this could work when Drupal itself is in a subfolder, like this:

Turns out it can. Suppose you want a new subsite called 'drupal-subsite'. Here's what to do in your webroot:

Your lolcathost(*) sees just another subfolder that's a site; the symbolic link sends you to the existing Drupal folder; and finally, the multisite system sees that you're browsing 'localhost/drupal-subsite' and selects the localhost.drupal-subsite folder as the one holding your site.

You can also have your subsite explicitly sit below the main site like this:

In which case your sites folder is localhost.drupal-multisite.drupal-subsite and the symlink should be inside the multisite folder:

So when I next get a moment I'll consolidate the various test sites I have, and when I have more than one patch on the go that I want to keep segregated, I can just add a multisite, get a fresh CVS copy of the code, and get going.

I've added details to the documentation too.

(*) yes, I keep typing it like that.

Situation: you need a heap of imagefields that more or less have the same setup. Let's not go into why.

You could spend half an hour bored witless clicking through the interface.

Or you could create just the one field, export the content type with content copy, and then doctor the code a little before importing it back in. Like this....

<?php
// The usual content type stuff here.
// Set of image fields
$image_fields = array(
  'field_image_1' => 'Image 1',
  'field_image_2' => 'Image 2',
  // etc
);

foreach ($image_fields as $name => $label) {
  $content['fields'][] = array (
    'label' => $label,
    'field_name' => $name,
    'type' => 'filefield',
    'widget_type' => 'imagefield_widget',
    'change' => 'Change basic information',
    'weight' => '-3',
    // the rest of your field export code here
    // don't forget to fix the brackets, as export code
    // comes out as a numerically keyed array.
    // and don't forget the closing }!
?>

Hey presto, heap of fields created in one go. Don't forget to set their weights nicely afterwards.

Okay, so I lied. But module builder can save you a lot of time when writing custom modules.

And it now works with drush, too. I added support for drush a few weeks ago, which let you do things like "$ drush mb mymodule cron init menu nodeapi --write" and hey presto, a new module folder is created, with an info file and a module file, with hook implementations ready to do your (evil) bidding. (Note: this blog does not sanction use of Drupal, module builder, or drush for evil.)

If you're super lazy you can even say "$ drush mb mymodule cron init menu nodeapi --go", using the wash 'n' go option which writes all the files and enables the new module for you. But don't do this if you're writing an install or enable hook, as they won't have any code in them!

The downside was that you needed to install module builder into each Drupal installation you wanted to generate modules for. Bit of a pain if you're developing a few sites and have a few more test sites kicking around.

But no more! You can now stick the module builder folder wherever drush can find it, and build modules in any Drupal 6 installation. You can download hook data to that installation with "$drush mbdl", or store it in a central location by specifying the --data option.

You might say at this point, core hooks are all very good, but what about hooks for CCK, Views, Ubercart, and so on? Well, like all good modules, module builder comes with a hook. Implement hook_module_builder_info, tell it where you hook documentation can be found on the interwebs, and add your module's distinctiveness to module builder's sugary goodness.

And how might you do this?

With module builder, of course!