I have been working on upgrading a site from Drupal 4.7, which is unsupported, to Drupal 5.14. I am somewhat familiar with Drupal as a blogger, user, and administrator, but wasn’t sure what it would take to upgrade a large and complicated site that’s been around for several years (and several former admins and programmers).
I decided to copy the entire site over to my computer so that I could run and upgrade it on a machine I completely control. I had already installed MAMP. If you develop on a Mac I advise you not to be snobby, MAMP is awesome.
The instructions at drupal.org looked pretty good. And Angela Byron from Lullabot has a good screencast on upgrading from Drupal 4.7 to 5.1x. If you are about do an upgrade, I recommend you watch this — it helped me get all the steps clear in my mind and it was also kind of reassuring.
One of the first things I did was to list out all the modules used in the old site. Later, I dumped them into a shared document so I could ask other people which modules they know are used or might be useful to bring to the upgraded site. I also started a plain text log file of what I was doing for the upgrade, to record things that worked and didn’t, links that were useful, commands, and so on. This sort of “work in progress” file gets messy very fast, so it’s good to go back over it before you stop working for the day to sum up what actually did, or does, work!
I started off here, Copying a site to a local MAMP installation on a Mac. I ran into a few problems and when I figured them out, I logged in to drupal.org so I could add to the documentation.
Then I ran into problems, because I wanted to run several instances of Drupal at once, and there were hard-coded bits of urls in several blocks of the 4.7 site. So I had a copy of the complete 4.7 site in a directory called “drupal”. Its .htaccess file was set up as in the “Copying a site to a local installation” instructions suggested. But half the links were broken – the ones that were hand-coded into blocks rather than pulling from the database. What I ended up with was another .htaccess file in the root MAMP/htdocs directory:
RewriteEngine on
RewriteRule ^$ /drupal/index.php?q=/ [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /drupal/index.php?q=$1 [L,QSA]
This worked. Now I have several folders with different versions of Drupal and several sites in my MAMP/htdocs folder, and to get them fully operational with all the links working, I change the path in the RewriteRule in .htaccess in htdocs.
Other people, in dealing with this problem, turn to virtual hosts, which is what we use in our production server. I haven’t tried setting that up yet, though it seems like once it was working, it would be more elegant.
Onward to the upgrade itself. I tried it a few times, and kept getting various bits wrong, ending up with a blank white screen and no information in the MAMP/conf/apache_error_log and nothing at all in “view source”. HEre’s some of the things I did wrong the first few times:
– ran upgrade.php from the old site’s directory. oops! Drop that database and start over!
– put the old site into maintenance mode, then couldn’t get to a login screen for turning maintenance mode off again, despite advice from the Drupal forums on “Site off-line under maintenance mode” to go to
http://localhost:8888/mynewdrupalinstall/?q=user
. I ended up turning off maintenance mode from the command line,
/Applications/MAMP/Library/bin/mysql -u root -p databasename
>> update drupal.variable set site_offline=1
That worked great.
Turning things on and off from the mysql command line turned out to be very helpful for a bunch of my problems. It was useful for manipulating themes. When I enabled the site’s old 4.7 custom theme — not even selecting it as the default theme, just enabling it — my entire new install gave me a blank white screen. Oblomovka suggested switching the directories around, which seemed like a great idea! So,
mv oldcustomtheme screwedupoldcustomtheme
cp bluemarine oldcustomtheme
We both thought this was clever and would trick Drupal 5.14 into going right back to the default bluemarine theme. No! It didn’t work! The white screen persisted.
This was helpful: Unusable theme – How To reset your theme via the database.
In retrospect, I should not have tried enabling the old custom theme before I turned on some more modules; when I actually bothered to look at the old theme, I could see it used jstools and all sorts of other stuff that I’d deactivated.
I’m off to try that now. So far this has been pretty interesting, though sometimes frustrating! The documentation on drupal.org is extremely helpful.
