6.x

This is now my first Drupal 6 to Drupal 7 upgrade. Not without hitches, but all in all not too painful. Hope you like the new look. As dedicated readers may know, I never stick with the same theme between major Drupal releases, more often than not because my previous theme was never ported and I can't be bothered to port it myself. The new theme is the rather pretty Corolla, which you can find here:
http://drupal.org/project/corolla

Here are some Drupal 7 upgrade notes and links others may find useful.

This post was going to be longer, but I just lost the entire completed document because the worst (and probably most expensive at $15/day, yes DAY) mobile Internet provider in the world, EVER, just dropped my connection mid-submission and for the zillionth time today. So you'll have to make do with an angry and hurried synopsis of what I would've written.

I'm an experienced Drupal developer. I've been embedding stuff in code for ages now. Views, Panel pages, ImageCache presets, even putting CCK content type exports in to hook_install() implementations just to try to keep stuff in code. Many of you are probably in the same boat. Keeping stuff in the database brings all sorts of ugly deployment and performance issues, so we avoid like the proverbial plague.

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