Today I took the plunge and upgraded apocryph.org to the latest version of the Drupal content management system. Drupal 6 has been in the works for what seems an eternity, and has a number of big improvements which made it hard to resist. Unfortunately, I now somewhat regret the decision, as there were considerable gotchas to cope with.

Of course, I started out with a complete backup of my Drupal 5.x site and database, just in case. I went through the upgrade steps in UPGRADE.txt, but despite being logged in to the site as the root user, I had to bypass security checks by adding the $update_free_access = TRUE; line in sites/default/settings.php. The upgrade itself went fine, but as another consequence of Drupal seemingly ‘forgetting’ I was logged in as superuser, after the upgrade the site was still in maintenance mode, and I couldn’t log in to change it!

Fortunately this post got me out of that particular jam, but it was still a gotcha that was definitely not present the last time I did a Drupal upgrade.

The next gotcha was one I’d anticipated: Due to major changes improvements to the theming system, my custom Drupal theme that implements the distinctive apocryph.org look and feel sucks hard under Drupal 6. I had to compare it to one of the themes that ships with Drupal 6 to figure out what was wrong. The big thing was that themes now need a themename.info file that contains some metadata for the theme. Since my theme uses custom regions, I also had to declare the regions in the .info file. Apart from that it was things like $language being an object instead of a string, and similar stuff. The Converting 5.x Themes to 6.x page helped alot, as did the writing .info files for themes page.

Once the theme was working, I set out to install the 6.0 versions of the various modules I use to run apocryph.org. Here I was in for an unpleasant surprise. The following modules were used in Drupal 5.x, and are not (yet, anyway) ported to Drupal 6:

• akismet
• commentrss
• gsitemap
• subscriptions
• taxonomy_access
• views

Since akismet and commentrss aren’t available, I’ve had to disable anonymous comments to avoid a deluge of comment spam. Without gsitemap Google has to crawl my site the old fashioned way and won’t pick up the structure of the site. The other modules I can live without.

Once I was resigned to the limitations imposed by the missing modules, I pulled up the site as an anonymous user to make sure it looked ok. Imagine my surprise to find that the site was blank! When viewed as an authenticated user all my content from the last two years was there, but to an anonymous user, the site looked empty. I tried pasting in the URLs to some of my blog posts into the anonymous browser window, but they all came back “access denied”. The Drupal log reported the access denied errors, but didn’t offer a clue as to what caused them.

I suspected this had to do with the fact that I ran Drupal 5.x with the taxonomy_access module, which let me specify access control rules for different vocabularies. Since this wasn’t in 6.0, I thought maybe the taxonomy_access module might’ve left some cruft in the Drupal database that was messing up the access control rules.

I did a little poking around, and ran into this support request for taxonomy_access. It turns out you have to go to Administer | Content Management | Post settings and click the Rebuild Permissions button to clear out access control cruft left over by taxonomy_access. Once I did that, all was well.

I hope the modules I need get ported to Drupal 6 soon, so I can reopen anonymous comments. In the mean time, I’ll try to convince myself all the spiffy new Drupal 6 features were worth the hassle.

UPDATE: I also had trouble with the pathauto module. The configuration left over from Drupal 5.x used token names like [user] and [title], but the new 6.x version of pathauto issues errors strongly urging you to use [user-raw] and [title-raw] instead. What’s more, it was configured to use the underscore (_) as a separator character in the generated paths, but was also defaulting to removing underscores from path names. I don’t know how it got that way since I wouldn’t have set that up in Drupal 5.x, but I changed it to leave underscores in place.