On October 17, a new security release of Drupal 5.3 came out to fix some potential issues with Drupal 5.2.

Sometimes, you have a Drupal installation with a few customizations in core. Or you simply do not want to perform a full upgrade by wiping existing files and replacing them from the tarball.

So, you can opt to apply the patches listed here, but there are too many of them, and if you have many Drupal installations, this will add to the amount of work.

So, in this article, I will describe how you can generate and apply the changes via a single patch file.

Steps for generating a single patch

The following steps describe this process:

Checkout Drupal via anonymous CVS.

Change to the directory you just checked out, and run the following command. This will create a patch file containing all the differences between Drupal 5.2 and Drupal 5.3 in one single patch.

cvs -q diff -uF^f -r DRUPAL-5-2 -r DRUPAL-5-3 > drupal-5-3.patch 

Run the following command to make sure there are no conflicts in the patch with your changes.

patch -p0 --dry-run <  drupal-5-3.patch

Make sure you get no errors from this dry run.

Then, run the patch for real:

patch -p0 <  drupal-5-3.patch 

Update Status considerations

One last thing, if you run the update_status module, and you really should be doing that, you will get some false positives about your installation being out of date. To avoid those errors, you have to change the modules/*/*.info to change (or add, if your original install is from CVS and not an official tarball) the version information there.

For example, for 5.3, the additional section (as it is in an official tarball) will be:

; Information added by drupal.org packaging script on 2007-10-17
version = "5.3"
project = "drupal"
datestamp = "1192656904"

Of course, changing a dozen or so .info files manually is a lot of work, but if you are applying the patch to a lot of installs, then you can do this once on a test system (you have a test system. right?), and then generating a patch that includes these changes as well.

This is left as an exercise to the reader. Post any comments you have.

The above instructions apply to any other releases, provided you know the CVS tags for the releases.

Updated: A Better Method

Thanks to Artisan Numerique, here is a better method, described as a series of shell commands

# Change the version below to what you have
# Change that to the directory where Drupal is installed
cd $TMP
# Download your current version
wget http://ftp.drupal.org/files/projects/drupal-$VER_OLD.tar.gz
# Extract it
tar -xzf drupal-$VER_OLD.tar.gz
# Now, download the new version
wget http://ftp.drupal.org/files/projects/drupal-$VER_NEW.tar.gz
# And extract that too
tar -xzf drupal-$VER_NEW.tar.gz
# Now create the diff file
diff -Naur drupal-$VER_OLD drupal-$VER_NEW > $PATCH_FILE
# Now change to the directory where your Drupal installation is
# Check that the patch would apply without errors
patch -p1 --dry-run < $PATCH_FILE
# Assuming there are no error from the previous step, you can
# now apply the patch for real
patch -p1 < $PATCH_FILE

Updated 2018-March

Though the recommended way is to use drush, there may be instances where this is not possible. Drush is used as follows:

drush @mysite up drupal

But if you don't have drush installed, or you are called in to a system where drush updates would not work (e.g. Drupal 6 LTS), then there is another way.

A better version of the above script, dvu (Drupal Version Upgrade) is attached to this article. To use it just invoke it without any arguments, and it will tell you the syntax. You have to know your present version, and the version you should upgrade to, and the directory where Drupal resides. This now works with Drupal 6 LTS, Drupal 7, and Drupal 8.

Binary Data Drupal Version Upgrade shell script2.23 KB


Sun, 2007/10/28 - 12:39

IMO, there should be official patches that do exactly this at d.o. That is, from a major Drupal release (5.0) to a minor one (5.1, 5.2, 5.3), and also from any minor to the next minor (5.1 to 5.2, 5.2 to 5.3). Has that been discussed before?

Sun, 2007/10/28 - 14:30

The approach mentioned in the above article is an alternative way that I thought of after I wrote the above article to address the issue of .info files, and the need to change those.

What it does is download the old and new release tarballs, extract them, and then create a patch from the differences.

This way, there is no need for changing the .info files manually.

Merci pour sharing ...
2bits -- Drupal and Backdrop CMS consulting

Tue, 2009/05/05 - 12:56

This is a variation on the method you described. It worked wonders for me.

The life saving command:

While inside your new upgrade Drupal folder, compare and copy files to your website folder.
find * -type f -exec cp {} /path/to/www/{} \;

And the follow up diff check to see if any changes linger.
find * -type f -exec diff {} /path/to/www/{} \;

Watch out for your settings file that got overwritten.
Commit changes. Done!

Wed, 2008/02/06 - 17:58

Curious to know how you are upgrading your core branch versions (5.x > 5.x) using cvs_deploy.module?


Mon, 2007/10/29 - 09:54

Another thing you can do is setup symlinks so that when a new Drupal release comes along, all you have to do is replace the symlink pointing to the latest Drupal 5 release...

Drupal/5 --> Symlink to drupal-5.3
Drupal/6 --> Symlink to drupal-6.0-beta2

Within this, you have the sites directory of the Drupal installs symlink to Drupal/sites, and files symlink to Drupal/files. Then, when a new release comes out, you just extract it, and update the symlinks to the new version. Easy!

Wed, 2007/10/31 - 17:04

Perhaps you missed a step? At least for me I had to add a step to make this method work.

Before this step:
Run the following command to make sure there are no conflicts in the patch with your changes.
I had to move the .patch file to the same directory as my Drupal installation before running it.

At any rate, thanks for this slick method of upgrading. I've had upgrades go horribly bad before, so I'm glad to find a quicker, easier way to do it.


Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting