Update May 27, 2012

I’m leaving this post up for History; however, the currently recommended way to update drupal core and drupal modules, for minor version updates, is to use drush (the drupal shell).

cd [drupal directory]
drush pm-update

Drush pm-update will: check for updates for your drupal instance, inform you of the current status of drupal-core and all of your modules and it will ask if you want drush to update your drupal installation. You can answer yes or no. It is safe to check the update status, drush will not make any updates until you answer “y”. You can also check for security updates only with:

drush pm-update --security-only

Back to previous post

I found a couple of drupal sites on a web server that were badly in need of security updates. They are no longer being maintained by a developer but they are still in use by a user community so I didn’t like the idea of taking them down just because they are a security vulnerability, as they still have a great deal of value for people who use them. So I decided to update them with the patches that are available at fuerstnet.

If you follow the link above to fuerstnet, the site provides patches from all of the minor versions of drupal up to the most recent security level. So, if you check your drupal site’s status at “admin/reports/status” (in drupal 6). And you see that you’re drupal version is currently drupal 6.14. (That’s 4 security releases out of date!) Then you can go to fuerstnet and download the drupal-6.14-to-6.18.patch security fixes only patch, or you can download the 6.14-to-to-6.20.patch (which includes bug fixes + security fixes.).

The first thing you need to do is make sure you have a current back-up of the database and the drupal file system.

1. Quick back-up of the file system:
cp -R DRUPAL_ROOT DRUPAL_ROOT-bk
2. Copy of database:
mysqldump -uDB-USER -p DB-NAME > ~/DRUPAL-SITE-NAME.db-backup-DATE.sql

or you can do the database back-up with drush:
drush sql-dump –result-file=~/DRUPAL-SITE-NAME.db_backup-DATE.sql
Of course, you need to replace all of the ALL_CAPS names up above with the names that correspond with your site. Now on to the update procedure:

The procedure, as outlined at fuerstnet, is:
1. copy the patch into you’re drupal root directory.
2. put your site into maintenance mode. “admin/settings/site-maintenance” (in drupal 6)
3. cd into the DRUPAL_ROOT directory.
4. patch -p1 –dry-run < DRUPALPATCH
(replace DRUPALPATCH with the name of your patch, ie drupal-6.14-to-6.20.patch) if you do not see any errors in the output of the patch command, then you can run the command again for real.
5. patch -p1 < DRUPALPATCH
Next you have to run update.php, which if you have drush you can run like so:
6. drush updatedb
or you can visit http://YOUR-DRUPAL-SITE/update.php
7. next: test your site, update any modules that need updating and then don’t forget to pull your site out of maintenance mode.

Another possibility is to run the upgrades in drush with the shell command:
> drush pm-update –security-only

This command will update your site with any available security updates. It will first show you a list of updates that are available and ask if you if you want to proceed. You must answer y or n. This command is great, because you can run it in the root directory of any of your drupal sites and it will show you which updates are available. Also if you have site-aliases set up, you can run it against all of your aliases one at a time and you don’t have to leave the comfort of your /home directory!

> drush @dev pm-update –security-only
(where @dev is an alias name for one of your sites.)

Of course you can run the update command without the –security-only and it will offer to update all of your modules, themes and core drupal files.

[However I ran into trouble with this approach as it updated the themes as well on one of the sites I was updating and the original site developer had customized the theme instead of creating a new them and customizing that! So I restore the theme from backup. Of course when drush updates modules and themes it backs up the old ones in a directory outside the drupal directory, so if there is a mishap, such as overwriting a customized theme, you can restore and clear cache to restore the old theme. Although there is that safety net, I still now prefer to update security-fixes only at first, and then run non-security modules fixes one at a time and run the theme fixes manually. Schwew, big aside.]

After running the drush pm-update, which can be shortened to drush up, I like to run a quick:
> drush updatedb
to make sure the database has been updated properly, and:
> drush cc all
to make sure the caches are cleared.

And once you have all of your sites aliased, it is simple to ssh into your web server and run the drush up –security-only command once a week to check that all of your sites are up to date with the security fixes.