HowTo: Updating Drupal 6.x to newer minor version

The update process described in this HowTo is based on updating three Drupal sites to v6.10 — one from v6.8, and two from v6.9.

You should encounter no problems updating several minor versions in one go — for example, from v6.5 straight to v6.11 — as the new version contains a file that will update the database and other settings, if needed, when you run update.php.

The instructions found in UPGRADE.txt (in the Drupal Core archive), existing handbooks, and tutorials mainly focus on the issues involved in upgrading to a new major version, such as Drupal 5.x to 6.x. When you are performing a minor version update, such as Drupal 6.8 to 6.10, you can safely skip a few of the steps that are required for major updates.

Target Audience

This HowTo is aimed at new users and new admins of Drupal. It includes specific details as well as helpful advice so you can 1) recover if you have problems and 2) better understand why you are doing something.

If you are a seasoned Drupal admin, read http://drupal.org/node/359234 for how to use a simple patch command to do minor Drupal upgrades.

Why skip removing the existing Drupal version?

Simply put, a minor upgrade usually does not trigger the conditions that call for some of the steps involved in a major upgrade.

For example, step 6 in UPGRADE.txt calls for you to completely remove the existing version. For a major upgrade, 5.x to 6.x, this is generally a good idea. The new Drupal version will have many new features, will no longer need some directories and files from the older version, and will organize others under a different directory structure. Filenames could even change. Consequently, unless you completely remove the earlier version, you risk having unused files sitting around, which could at least cause confusion and might even pose a security risk.

But minor updates mainly entail improvements to security and bug fixes. There is no major reorganization of files or directories, so it is relatively safe to carry out the upgrade without removing the existing installation.

A side benefit of skipping this step is that any files that have been copied to a core directory (other than /sites), and are not part of the Drupal Core will still be there after the update. You will not have to restore those files manually after the update.

But check release notes and announcements first

When you do a minor update, always check the release notes and announcement for each version that has been released since the version you are currently using. Especially if you are updating to a much newer version — for example, updating Drupal 6.2 to 6.10 — the new version might entail quite a few changes. In rare cases you might want to remove the old installation before you carry out a multiple-version minor update.

Don’t Modify Core Files

If you want to move yourself from the largest support communities to the smallest, go ahead and modify core. If something goes wrong, you will pretty much find yourself on your own. You might even make it impossible to update your site to a newer version when needed.

If you need to change the Drupal Core behaviour, there are many ways to do so without hacking the core code itself. Some changes might require custom modules. Others can be accomplished at the theme level. Still others might only require a change to settings.php. None of these methods is as drastic or as risky as is hacking core.

Two Useful Modules

Two contributed modules can make the update process easier to perform:

• Backup and Migrate. This module makes it quick and easy to back up your database directly from the Drupal administration interface. You can then either download the backup file or save it in the site directory. A very useful feature of this module is that it can be configured to back up just the table structure of the cache tables, which will reduce the size of the backup file. (The data in the cache tables will be regenerated as soon as they are needed again)
• Contrib Toggle. In many cases, to disable all non-core modules requires several steps. This is because some modules are blocked from being disabled until other modules that depend on them have been disabled first. Contrib Toggle can do that for you automatically.
  This module was not used as it was not known by the author until after all sites already had been updated. As of this writing there is only one open issue about a conflict with the Devel themer module. In the forum comment from January 18, 2009, it also says that it does not work properly on sites with a very large amount of non-core modules.
  As of this writing, Contrib Toggle does not remember which modules you have enabled. This feature is planned for v2.0. Until that is implemented, make sure to note which modules will need to be enabled again after the update is complete. Doing so will save time and countless clicks.

Performing the Update

Some of the text in these steps has been copied directly from UPGRADE.txt, as they are performed in the exact same way.

Replace www.example.com with your domain name and path in the steps below.

Stage 1 — Prepare the Update

1. Make sure your system meets or exceeds Drupal's minimum requirements. As it is a minor update it is very unlikely that your system will not meet them.
2. Download and unpack the latest Drupal 6.x to where you will upload or copy it from. It will create a folder called "drupal-6.[minor version]" with all the files and directories in it.

Stage 2 — Back up current site and put it Off-line

1. If possible, log on as the user with user ID 1, which is the first account created and the main administrator account. User ID 1 will be able to automatically access update.php in stage 3 step 2. There are special instructions in that step if you are unable to log on as user ID 1.
   Do not close your browser until the final step is completed!
2. Place the site in "Off-line" mode, to let the database updates run without interruption and avoid displaying errors to end users of the site. This option is athttp://www.example.com/?q=admin/settings/site-maintenance.
3. Back up your database.
4. Turn off all non-core modules. Don't forget to note which non-core modules you have enabled so you can re-enable them again after the update.
5. Backup the "sites" directory and other files. The "sites" directory contains your configuration file, added modules and themes. It also contains contributed or custom modules in your "modules" directory, and your "files" directory which contains uploaded files. If other files have modifications, such as ".htaccess" or "robots.txt", back them up, too. Check these files in the new version, you might need to modify your modified versions of them

Stage 3 — Perform the Update

1. Upload the new version.
2. Select all directories, except the "sites" directory, and any files such as ".htaccess" and "robots.txt" that have been customized to your site. Then upload or copy them using your preferred method such as an FTP client. When the warning appears that the directory or file already exists, select overwrite for everything.
3. Run update.php by visiting http://www.example.com/update.php. This step will update the core database tables to the new Drupal installation.
   Note: if you are unable to access update.php, follow these steps:
   1. Using a text editor, open your settings.php file.
   2. Find the line that says $update_free_access = FALSE;
   3. Change that line to $update_free_access = TRUE;
   4. Now run update.php.
   5. When the update is complete, change the settings.php file back to its original form with $update_free_access = FALSE;
4. Re-enable your non-core modules and run update.php again.
5. Finally, return your site to "Online" mode so your visitors may resume browsing. This option is available in the administration screens at http://www.example.com/?q=admin/settings/site-maintenance.

You now have an updated Drupal 6.x. Take a look around the site to make sure that everything is how it should be. Especially check all your CCK-based content types you have for the inactive problem mentioned below.

Known problem

Only one small issue has so far been discovered using this update process. Existing Fivestar CCK fields were marked inactive even though the Fivestar module was enabled. Fivestar wasn't showing on content pages, nor when editing the content type or in forms. If you get this problem, you can find a fix in this issue comment. The same fix will most likely work for other CCK fields with the same problem.

More help and updating support

In the Upgrading Drupal forum there is a lot more information and help about updating and upgrading Drupal.

Problems with contributed modules after update

If you have problems with a module after the update, check the issues for that module. In some cases the problem is not the module you first thought, but the module it depends on. Therefore also check the issues for them as well.

Disclaimer

Even though this process has been reported to work without any big problems, that is no guarantee that it will work for you. If you are not ready to perform it on any production site, you can always try it on a test site first.