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.

So we've done all French sites before. And we've done all English sites before. But a recent project was our first real forray in to multilingual sites and it's an e-commerce/Ubercart job! Talk about gluttons for punishment!

There are bags of tutorials, so I'll keep this short but sweet. A list of dos and don'ts from our painful, recent experience:

1. Don't change the default language after initial set-up. Set your default language right at the start and don't mess with it. Ever.

For a recent custom module I was building I was faced with the challenge of having to create a bunch of nodes from data stored in an XML file.

I decided not to use Feeds or Node Import modules for a couple of reasons –

1. The XML structure was fairly custom (it was coming out of one of our internal .net databases – euugh!)

Important edit: Seems it doesn't work with Google Apps accounts - apologies to Zach in the comments, you were quite right. I'm revising this post. However, it does still work as described with all Google Mail domain accounts (e.g. personal Google accounts).

So, OpenID. Been about for a while. I kind of knew how it worked. I also knew I had dozens of OpenIDs, all in places of no use to me whatsoever that were generated automatically when I signed up for some service or other.

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.

Quick post this evening, because I'm stopping for the day. Just a troubleshooting tip for web services. We use the excellent Drupal Services module quite a lot for integration work. Take a look, if you don't know it:
http://drupal.org/project/services

Anyway, we always switch on the full security options, which are great for securing the API but stacked full of nasty gotchas. I had a new one today and I thought I'd share.

Part of building an authentication token for the Drupal Services module is adding in a timestamp. The code we normally use looks like this:

<?php

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:

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.

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) {

I happened across a wee bug in Views 2 today. I think I've noticed it before, and I'd be a monkey's uncle if it isn't already in the queue, but this is a synopsis:

If you expose the Node Type filter in Views 2 and set it to "Optional", but also with "Limit list to selected items" checked, you might expect it to continue to restrict the results to the selected items it refers to, right? (Well I did.) It does not. If your use selects the "< Any >" option from the resulting UI they will get *everything*

Doh!!