7.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.

I'm not a fan of repeating myself, or of doing the same work twice. So when I first got a look at FieldAPI back at DrupalCon Paris, my thought after 'Wow this is going to change everything,' was 'Every module that converts its custom data storage to this is going to be doing the same work, over and over'.

This is a quick post while it's fresh in my head, regarding porting your contributed modules to the Drupal 7 API. This post specifically focusses on database manipulation and provides the like-for-like changes. If anything here is wrong, or could be done better, please let me know!

First up, individual results:

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.

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.

Every time you build a new application in Drupal you *always* have to carefully govern the number of options available to normal site editors, or their heads will explode. (Literally. I've seen it.)

Almost every module you install will put something more on the node forms, until you end up scrolling forever just to reach the Save button. Not to mention most of this stuff you won't want them playing with anyway.

Yay! My first blog post with the 7.x tag! It's coming up fast, folks... Shame this one is a gripe.

Courtesy of an issue I raised some months back regarding the update system registering updates in the system table, even if they fail, I came across an interesting and (IMHO) bad decision regarding update.php in Drupal 7:
http://drupal.org/node/595550

I'm prompted to write a post that is a bit less technical and more of a muse on the state of the Drupal project. Anyone who follows the community will know much is made of a developer/designer divide. To be honest, I still don't quite get why this is. I don't personally feel it.

I have finally put pen to paper on my germinating ideas surrounding a Drupal module for publishing Drupal content and applications via Adobe AIR.

Well, I'm in the throes of trying to contribute to core for the first time, and I have to say, it's a painful experience. Your concepts and code are suddenly thrown open to pretty fierce scrutiny by the community at large.

When you're making your own module no one really cares what you do, as long as it doesn't compromise the security or operation of other modules. Not so with core. There can be some pretty harsh debate around what can and cannot go in to the framework.