Our Drupal Upgrade Experience
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.
Windows Server 2003
Apache 2.2.11 with mod_ssl
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:
- Update the text of the welcome email for users awaiting administrative approval
- Enable the update status module
- Flesh out edit/delete permissions, as Drupal 6 has split those actions into different permissions categories
- Look at user signatures, as the default input format has been changed
- 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.