Drupal 5.x to Drupal 6.x upgrade

Note: this was written before the upgrade of my Drupal Scripts Library to use Drush rather than CVS (or Git).  See my post on this subject.

I undertook the upgrade of this site, toddgee.com from Drupal-5 to Drupal-6.  This assumes that a site was deployed using my Drupal Scripts Library (which makes the process MUCH easier.)  In preparing this, I did a lot of surfing around to see others' instructions.  I hit too many sites to link to them all, you can do the same Google search I did.  Below is a list of instructions based on how I accomplished the task.  Some sites I found notable:

  • http://drupal.org/node/340073
  • http://drupal.org/videocasts/upgrading-to-6
  • http://becircle.com/how_upgrade_drupal_5_drupal_6

Note the following conventions used below:

  • {domain} is the domain I'm upgrading. In the case that drove this post, it's "toddgee.com".
  • {devdomain} is a development domain I have set up and for which I have a separate mysql database available.

Let's get started!

► I first read the official Drupal-5 to Drupal-6 README file distributed along with drupal.  You should too.

► Next, using drupalSiteDupe.sh, make a copy of the site onto a development subdomain.  This allows you to work on that copy, testing these instructions and making sure the process worked, and not touching the original site.

$ drupalSiteDupe.sh {domain} {devdomain}

Note that this command can also be configured with the db connection information for the DB backing the development site.  It's not required if you've set that information up before (it extracts it before clobbering the site with the copy).  See script header for more info.

► Start work on the dupe site by putting it into maintenance mode.  Chances are that no one will hit it (since it's on a dev subdomain); but better safe than sorry.  On my site (this site), I have some nodes protected by the private module; when that modue is deactivated below, those nodes become instantly public.  Can't have that!

$ drupalDBQuery.sh setoffline {devdomain}

Note that putting a site in maintenance mode hardly requires a script, I just find it easier to do everything from the command line.  That's how the Drupal Script Library came into being!

► Switch the dev site to the garland theme.  For my run, this wasn't necessary as I already run garland.

► Generate a list of all enabled modules for future reference using the drupalReport.sh script.toddgee.combe used when I re-enable them after the upgrade.

$ drupalReport.sh status {devdomain}

Note that this script will also tell you of any pending updates to drupal core or any modules.  If any modules are shown to have updates (highlighted with a '*'), you should update your original site to the latest code before jumping to a new Drupal version.... After it is updated, you can again begin with the drupalSiteDupe.sh command.

► After copy-and-pasting this output to a text editor someplace, disable all contrib modules:

drupalDBQuery.sh "update system set status = 0 where filename like 'sites/{devdomain}/modules/%' and type = 'module';" {devdomain}

If you want to, you can ensure that all modules are now inactive:

$ drupalReport.sh statusnc {devdomain}

You'll now notice that all the installed modules report "*NONE*" for active modules...

► Now comes the fun part -- updating the Drupal core and all the modules to their cooresponding Drupal-6 revisions:

$ drupalCVSDeploy.sh -versiontag DRUPAL-6 update drupal {devdomain}
$ drupalCVSDeploy.sh -latestversion update allmodules {devdomain}

You'll also need to update any contrib themes you have installed (part of the 'drupalReport status' report):

$ drupalCVSDeploy.sh -latestversion update theme {theme name} {devdomain}

The Drupal Script Library makes things easy!

► Now you need to update any custom modules you have installed. See http://drupal.org/node/114774 for more information on the process. Similarly, you need to update any custom themes. More info on this at http://drupal.org/node/132442

► Before you can proceed, you need to update the settings.php file to now look like the Drupal-6 version. Follow these commands: (Note the the 'dcd' command is contained in the script 'bashrc_drupal.sh'.)

$ dcd {devdomain}
$ mv settings.php settings.old.php
$ cp ../default/default.settings.php ./settings.php
$ cat settings.old.php | grep '^\$db_url = '

Now copy this line and edit settings.php and overwrite the default definition of this variable (on line 92 of the former default.settings.php file as of this writing). Now you should a correctly formatted settings.php file which is compatible with the next step. You can keep or discard settings.old.php as you wish.  Ensure that the file is not writable by the calling user.  (Consider running drupalSetPerms.sh)

► The site now needs updating.  If you're not logged in as the admin (uid = 1) user, you have to update the settings.php file to allow access.  Fortunately, this can be done from the command line:

$ drupalSetAccessCheck.sh false {devdomain}

► Now hit http://{devdomain}/update.php to update the Drupal core and all the contrib modules. Hopefully you'll have no issues. Issues I encountered in updating various sites will be covered in later blog posts.

Now, all the HOWTOs say to update the Drupal core before the contrib modules.  When I ran this, it ran fine upgrading everything at once.  YMMV.  If you want to upgrade them separately, you can rename the modules directory in the sites directory before hitting update.php, then renaming it back and hitting update.php a 2nd time.

► With everything updated, you can now go back thru and enable all the modules you disabled above.

► Turn the access check back on.

$ drupalSetAccessCheck.sh true {devdomain}

► You can now switch back to your original theme.

► Go thru your site and find any PHP code in blocks/nodes etc. and make sure it is compatible with the Drupal-6 API.  Fix as necessary.

► Now we're done, so put the site back online:

$ drupalDBQuery.sh setonline {devdomain}

► w00t!

Now that the copy of the site has been upgraded, and you've figured out how to resolve any snags, you can now go ahead and update the original site. Basically, this involves performing all the steps above (except the drupalSiteDupe.sh step) and replacing {devdomain} with {domain}MAKE SURE YOU MAKE BACKUPS ALONG THE WAY.  Back up not just the sites dir, but the whole installation as well, and the database.   Make liberal use of drupalDBBackup.sh and drupalBackup.sh.  MTFBWY.


Free Tag: