Last updated October 4, 2012. Created by tsvenson on March 4, 2009.
Edited by laken, Steven_Bradford, aaron_michels, LeeHunter. Log in to edit this page.

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 upgrades.

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.

A Useful Module

A contributed module 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)

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 at http://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.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

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.

Why is it necessary to turn off all non-core modules during minor version update?

It is the official recommended method for upgrading/updating a Drupal site.

Personally I do it like this:

1 - Full backup using the Backup & Migrate module
2 - Put site in maintenace.
3 - Update all contribs, if any needed
3.1 - Another full backup if contribs are updated
4 - Delete all Drupal files except the sites folder and .htaccess
5 - Upload the new version
6 - Run the update.php

This is of course after I have tested it on a dev site using the backup taken in step 1, including testing with any contrib updates.

--
/thomas
www.tsvenson.com

The requirement to disable them all takes more time than any other aspect of upgrading. It's such a tedious procedure taking a good few minutes of concentration and multiple passes through unticking things and writing down, with a high risk of wrongly disabling core modules. Is it designed to drain your spirits and induce feelings of despair in order to weed out less determined Drupallers, or is that a bonus?

I'm sure it's already been proposed, but why not have one click box which says "disable all non-core modules and record them" and another which says "re-enable all previously disabled modules". Presumably it's sorted out in Drupal 7.

I'm not sure I agree with the step of turning off all non-core modules: I did this when upgrading to Drupal 6.22 and found that the positioning and visibility settings for several of my blocks disappeared. According to the posts at http://drupal.org/node/1173012, specifically comment 23 (http://drupal.org/node/1173012#comment-4552410), details for blocks that belong to disabled modules are lost as part of a cleanup mechanism in D6.

Luckily I was trying the upgrade out on a dev site first, so I just refreshed my dev site with a copy of the live site and tried the update procedure again, this time leaving any modules that were enabled still enabled. The update seemed to go fine that time.

However, the author (carlos8f) of the aforementioned comment does seem to have come up with a patch to fix this problem (see said comment). I haven't tried it though, because everything seemed to go ok when I left the modules enabled.

Hope this helps someone,

David

. there's a big alert in top of the contrib toggle page that says : dont' use me
. step 2.4 it says : 'Turn off all non-core modules.' anyway I can't disable the core modules.. (6.13). and what about the core-optional module ? :)

I downloaded and installed contrib toggle before looking at its whole page, so I didn't see that warning at the top. Turned off all the contributed modules with a click, updated Drupal, then saw the warning on my site that said "One of your modules is not supported". So I uninstalled Contrib Toggle. Sure was nice while it lasted.

If you've played with the menus at all, it's a good idea to switch to the Default Theme before you turn off Views and Nice menu and Admin Menu Modules; otherwise you may not have easy access to the Navigation Menu admin items you'll need.

I have (mistakenly) added non-core modules to the /modules folder rather than to the sites/all/modules folder, so now I have a lot of non-core files mixed in with the core. Can I just do the upgrade by manually replacing each of the individual core files - that is, surgically working around the non-core folders and files that I've added? Or, if I move all of the non-core modules to sites/all/modules, would the system still know where to find them?

I have written a similar tutorial. Have a look....! I hope people would like it.

http://www.geoindya.com/updating-drupal

Thank You for the detailed instructions of how to update.

Kindest regards,
MerjaS

MerjaS
www.gurux.org
------------------
Drupal 6.22
MySQL database 5.0.77
PHP 5.2.8
server Microsoft-IIS/7.0

The backup module is excellent!

Updating minor versions should not be a major activity, like the instructions above. We should be able to update my 1)backing up datebases, and 2) clicking on an option to update the system.

Apparently, this subject has been discussed, before, but the option is still not there. Why not?

Hi folks,
Have been following instructions: HowTo: Updating Drupal 6.x to newer minor version. On 3.3 (running update.php) I got the following...
Fatal error: Call to undefined function lock_acquire() in /home..../sites/all/modules/system/system.module on line 810
How do you update the core database tables to the new Drupal installation by visiting http://www.example.com/update.php??

Thanks