You are here

Updating a Drupal-6.x System

Submitted by h2b on 17. August 2010 - 18:21

A Drupal system shall be updated within the 6.x series – core, custom modules or both.

This howto is a short description for experienced Drupal administrators who want a check list for system updates. Thus, it is assumed that the basic update mechanism including the server directory structure is known. Furthermore, it is assumed that all administrative actions on the website are performed with appropriate permissions. Finally, it shall be emphasized that here only updates of a Drupal core version 6.x1 to 6.x2 or of custom modules for 6.x are considered (minor updates); major updates (e. g., from 5.x1 to 6.x2 or 6.x1 to 7.x2) as well as updates of custom modules between different major core versions are not considered here.

A comprehensive guide for updating especially the core system (inbetween the 6.x series) can be found as part of the Administration Guide on at this Howto. Beginners should read that first.

The steps for updating custom modules are basically a subset of the corresponding steps for updating the core system. Therefore, both are collected here together, where steps that only apply to the core system are marked by colour and text [core].

Updating a system is always dangerous. It can end in a non-functional system or can cause arbitrary damages. Therefore, the following steps are done on your own risk and without any warranty!

  1. Download the files to be updated and unpack them if appropriate. [core] From the local copy, delete the files .htaccess, robots.txt and the directory sites, if not has been stated that these were updated. If they were updated however, you probably have to do manual changes to them; in this case, you should include the files in question into the backup from the server (see below).
  2. Switch the website into maintenance mode.
  3. [core] Make a Backup of the files from the server. Use a suitable FTP pogram like FileZilla or Konquerer. It is on your choice whether to save all files from the server or only the sites/default directory (the latter contains among others the settings for the website and uploaded files). It is not an error to apply this step to updates of contributed modules also, although not imperative when treading very carefully.
  4. Make a Backup of the database. This is unconditionally required, because at each update unforeseen things can happen You can use, e. g., the backup_migrate module or even phpMyAdmin. It is no bad idea, from time to time to use the one or the other method to have different restore options if the case arises.
  5. [core] Disable all custom modules. Before, take down the current state as – for instance – screenshot (maybe by virtue of Firefox Shooter) or manually. You will need this for re-enabling the modules!
  6. When updating custom modules, delete the concerned old files from the server. This is recommended, since otherwise non-overwritten files may cause inconsistencies. [core] When updating the core system alone, this is generally not required, as long as a minor update within a major series (here: 6.x) is concerned.
  7. Copy the new files to the server into the dedicated directory, respectively (generally under sites/all/modules or [core] the document root directory).
  8. Call update.php.
  9. [core] Re-enable all previously disabled custom modules and call update.php again.
  10. Switch the website  maintenance mode off.
  11. Check the updated website.



According to step 5 ([core] Disable all custom modules...), during the update of the core system all active custom modules should be switched off; in step 9 ([core] Re-enable all previously disabled custom modules...) the reverse operation takes place.

This procedure corresponds to  the documentation in the file UPGRADE.txt of the Drupal core system (for version 6.25, e.g., these are the items 5 und 12 there).

These two steps belong to the most expensive tasks during an update of the core system, since the custom modules partially depend on each other and can't be switched on and off arbitrarily; furthermore, one has to be very careful when re-enabling the modules to re-establish the initial status, because otherwise the whole system might not behave as thought anymore. Hence, this is a potential, not to underestimate source of failure.

Now, there are hints (say here), that this disabling of custom modules during a minor update (i.e., from 6.x1 to 6.x2, say – and only such is in question in this contribution) is unnecessary. I tryed it out meanwhile for two systems and two core updates, respectively (each from 6.22 to 6.23 as well as from 6.23 to 6.25), i.e., leaving out steps 5 and 9, without any problem appearing. Of course, there is no guarantee for general validity (every system is different), but it may be worth a try – obeying the safety measures described above and on your own risk.