Site upgrade, throwing in new Drupal modules
I've been enjoying a nice vacation - the Sun is shining, so to speak :-). But a couple of days I've enjoyed upgrading www.openlife.cc to a newer drupal version, and also adding some much delayed blogging and Web2.0 enhancments.
Notes about the upgrade process (Drupal 4.7 to 6)
I had never upgraded openlife.cc, so I had to go through 2 major version upgrades. To do this, I created a staging site on my laptop so I could spend several days fixing things that would and did break when upgrading.
I followed the advice in the README file and disabled all addon modules before upgrading. Eventually I realised that this would actually break some formatting in blog posts that depended on those modules. For instance images uploaded through the img_assist module disappeared and I believe some clickable URL's became unclickable. After the upgrade I didn't find an easy way to make the images appear again (like deleting the cache) so I resorted to manually re-submitting the few articles which do contain images.
Lessons learned: For a major Drupal version upgrade, don't expect things to go smoothly. Do the upgrade offline, then publish the new site, otherwise things will break!
Wishlist: While I like Drupal, and you don't do upgrades like these so often anyway, it is a small handicap that content, settings and site elements (like blocks) are all in the same database. So for instance, during this upgrade I couldn't post stuff on the old version of openlife.cc that was still live, since those posts would not be included in the copy that I was busy upgrading offline.
New theme, same look
One of the things that horribly broke was my Vineyard theme (which I still haven't published GPL btw, sorry). It was originally based on Chameleon and written in the legacy Drupal theme api from pre 4.7 days. I quickly realised that trying to fix it was not worth the effort, so instead I took the Bluemarine theme from Drupal 6 and modified the colors and layout to look like the old theme. So now I conveniently upgraded to the recommended PHPTemplate theme engine.
There are three things I'm proud about with my theme:
1) The grape's attached to links is done as a CSS background image. (Like the grapes in the bottom left of the browser window too.)
2) It does not look too much like standard Drupal themes. I removed all borders so it is just plain green, and I've positioned the left navigation menu higher and the right block column lower than the main content, so it shouldn't look too "boxy".
3) I finally implemented something I already tried to do earlier: horizontal enumeration of the header and footer block areas. Drupal blocks are div, elements, so they are usually output on top of each other in the browser.
I added following code to page.tpl.php
// $Id: page.tpl.php,v 188.8.131.52 2009/04/30 00:13:31 goba Exp $
// TODO: According to Drupal Theming Guide code like this should be moved to some separate pre-processing file, for cleanliness.
// By default block sections is a consecutive list of div elemenents and are rendered top to bottom.
// Here we add </td><td> between each div, so that they become their own cells instead, and rendered left to right.
$header = preg_replace('|</div>(\s*)<div |', '</div>$1</td><td valign="top">$1<div ', $header);
$footer = preg_replace('|</div>(\s*)<div |', '</div>$1</td><td valign="top">$1<div ', $footer);
Yeah, I know, we are not supposed to use a table for layouts anymore, but it is so much easier than pure css - above else I don't need to test it with a zillion browsers because I know it will just work.
So now for instance the RSS icon and the Login|Register|Forgot password snippet in the top right corner are Drupal blocks, but they are laid out horizontally, not on top of each other.
Drupal modules sweetness
Apparently "Many people [...] are still building their websites with HTML, or custom PHP". Well, you shouldn't. You get so much free when using a great CMS like Drupal. In fact, the free stuff can be a bit overwhelming as I spent a few nights just to browse and download and install all the free addon modules. Drupalmodules.com is of great help there, since Drupal.org doesn't categorize (not to mention rank!) modules in any helpful way.
These are the modules I have installed:
antispam - uses Akismet service to stop spam. It already prevented 2 spams while I was writing this.
autosave - saves drafts of my blog posts in case the browser crashes (or as happens when I use Thinkpads, I accidentally hit the back key and may lose a post :-(
captcha - asks a tricky question when posting a comment, to prevent automated spam.
chatcatcher - not enabled yet, but should be a kind of pingback for twitter and other chat services.
comment_notify - enables (also anonymous) commenters to get an email when someone follows up on their comment.
footnotes - my own module developed originally for openlife.cc, now having dozens of users (at least)
globalredirect - adds redirects after enabling pathauto
image - helps upload images and attaching them to posts
pathauto - creates friendly url's of all posts. (/blog/2009/06/new-blog-post rather than /node/12345)
pingback - Creates a comment when other blogs link to my blog posts (supposedly commenting on them)
poormanscron - run's cron jobs triggered by http requests
scheduler - enables me to write a blog post to appear in the future, ie it doesn't need to be published at the time I write it.
tagadelic - helps create the tag cloud you can see at the bottom of each page (it is actually created by a php snippet I once found on drupal.org)
token - this was needed by pathauto I think
twitter - posts every blog to my twitter account
views - this was also needed by some other module
The general theme of the upgrade was to upgrade the blogging freatures of openlife.cc and I'm pretty pleased with what those modules offer. Anonymous commenting should now be convenient thanks to akismet helping prevent spam, and I'm eager to see the pingbacks work too. Friendly url's from autopath should make coming to openlife.cc easier too.
Independently I've also installed the Twitter application on Facebook, so my tweets also become Facebook status posts. And to close the loop I added Facebook and Twitter widgets to the right column of openlife.cc, as you can see.
There was one module prev_next I wanted to use to provide "previous" and "next" links for blog posts. But it felt a bit unfinished/hackish so I didn't use it after all - I guess the Recent blog posts block to the right will have to suffice. For instance, to actually get any previous or next links, you had to copy paste quite a lot of code into your theme. Then I also discovered the ordering is based on drupal node id's and not something like the publication time. So it just seemed better to forget it, since I would have had to code quite a lot to make it what I wanted. (For a simple use case like photo album it would have worked, which seems to be the original need it was developed for.)
MySQL issue with anonymous user and another with collation
At some point I realised a lot of comments had disappeared. I thought it was related to the upgrade process, but was actually an issue with MySQL and moving between databases.
At first it seems that when deleting all inactive users from the user table (ie the spambots) I also deleted the anonymous user, which has status set to 0 too. When I re-created it, it got assigned a new uid, since the table has auto-increment on. But Drupal assumes the anonymous user to have uid 0, so things still didn't work. After some googling I finally found others with the same problem, and UPDATE ... SET uid=0 helped fix the problem.
However, the same problem reappered when I migrated to the web hosting site to finish the upgrade. It seems that when you insert a row with primary key set to 0, mysql interprets that as "insert autoincrement key here". So every time you dump and reload a database the user with value 0 will get some other uid instead, which is very problematic.
Seems like mysqldump should make use of NO_AUTO_VALUE_ON_ZERO and always set it, I don't see a reason for ever not setting it. (Note to self: So go file a bug on it...)
The other reason some content disappeared was that drupal generated errors when trying to join some columns that were using the utf8_unicode_ci and utf8_general_ci character sets. Seems like when I first created my Drupal 4.x site the former was used, and now newly created tables use the latter one and you can't join columns of different types. Since I had the mysqldump file handy, I just replaced all old collations to the new one and re-created the database (rather than doing alter table).
I knew this isn't the proper way to fix such a problem, because when I finally published my site, of course it had Scandinavian characters now messed up. But since openlife.cc is mostly in English, I resorted to a manual fix and edited all posts which contained Mårten, Arnö or the € sign, and some other stray occurences I could find - like a guy called Särelä who rallied against the Finnish EUCD/DMCA law. (But to those who have bigger problems than that: I once found a php script in the mysql manual which can actually fix the character sets for you in place, which you usually should use.)