Skip to content

Our Drupal Upgrade Experience

August 12, 2009

Today (August 12th, 2009) I am attempting to complete our last test upgrade of a Drupal installation from version 5 to version 6. I’ve done this upgrade twice already while working on a local server at home, but this is the first time I’m trying it at work, on “real” servers. I’ll be using this blog post as a running log of the experience, with gory details after the break.Our Starting Point

The stack we’re working on is made of two servers – one for web, the other for the database.

Web:
Windows Server 2003
Apache 2.2.11 with mod_ssl
PHP 5.2.9-2

Database:
Windows Server 2003
MySQL 5.0.x (not sure the point release)

The website in question is a community resource for our school. It runs on 5.19 currently, with the abac theme and perhaps two dozen additional modules.

Hiccup #1: the system directory

The first hiccup I’ve come across is the /system directory. This is actually pre-upgrade – in order to do the test, I’ve copied the database and all files to our testing server, and added an IP-based virtual host to accomodate the test. In setting up the content on its temporary home, the user headshots have broken. They work on the production server, but on the temporary upgrade server, they’ve broken.

The files are being referenced at a path like “/system/files/pictures/picture-97.jpg” – which doesn’t exist. On both the production and testing server, the headshots are actually in the “/files/pictures/” directory – but the production server is capable of re-mapping a request to the “/system” directory, while the new testing server is not.

Core Update Complete

After following the first nine steps of the upgrade.txt instructions, I’ve now completed the core update. This has generated five messages, but no hiccups or problems. The five messages are, essentially, to:

  1. Update the text of the welcome email for users awaiting administrative approval
  2. Enable the update status module
  3. Flesh out edit/delete permissions, as Drupal 6 has split those actions into different permissions categories
  4. Look at user signatures, as the default input format has been changed
  5. Adjust permissions with the Blog API module, as those permissions are distinct from blog permissions

Hiccup #2: HTTP Request Status

After completing the core upgrade, I’ve enabled the update status module and run cron. However, the status page lists another problem – “HTTP request status” fails. I wonder whether this is related to the first hiccup, that of the user profile photos not showing up correctly. I’m going to try and upgrade the first batch of modules (activitystream) before looking at this more closely, but this will have to be something I tackle sooner or later.

The first link I’m looking at to resolve this is http://drupal.org/node/222454 – not sure if it is going to be useful.

Activity Stream: file system settings

The production server’s upload directory (actually the whole drive) doesn’t exist on the temporary server, so I had to re-map file uploads to a new drive/directory. No problem there.


Thoughts?

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: