How to easily upgrade Drupal from one minor version to another with a patch file

Upgrading Drupal from one minor version to the next can be time-consuming and error prone. A lot of folks use Drush for this, but a good second choice for the commandlinophobic is to use a patch file. 

Bernhard Fürst creates patches from all previous minor versions of Drupal 5 and 6 to the current release and posts them here. I've used this method several times, and it's gone really smooth.

First, go to your sites /admin/reports/updates page and see what version of Drupal you're running. Here's what mine looks like:

So, I'm on 6.16 and need to upgrade to 6.17.

Next, go to the list of patch files and find the one that matches up with your version. Click on it to download:

Move the downloaded patch to your Drupal site's base directory.

Now, we need to move to the command line. Sorry, commandlinophobes.

First, cd to the directory where you just put the patch file.

Before we run the patch for real, we're going to do a quick dry run to make sure that we don't get any errors. You'll need to use the actual patch file name you downloaded:

patch -p1 --dry-run < drupal-6.16-to-6.17.patch

You'll see a list of everything that gets patched. If you see any errors having to do with HUNKs, then you should probably use another method to upgrade.

If everything looks good, then run the patch for reals:

patch -p1 < drupal-6.16-to-6.17.patch

Now, run /update.php.

Update: Check out an article Kalid posted in the comments that shows how to automate this process via the command line. It's more command line-heavy, and if you're going to get that heavy it's just a tiny step over to using Drush, but is still pretty cool.

Here's some additional information about upgrading if you run into issues:

The handbook page on upgrading with patches
The handbook page on upgrading in general
The list of patch files
* Also reference the UPDATE.txt file in your Drupal site's main directory for more information

Prupal 6.16 Update available Recommended version: 6.17 (2010-Jun-02) Download Release notes Includes: Block, Color, Comment, Database logging, Filter, Garland, Help, Menu, Node, PHP filter. Path, Search, Statistics, System, Taxonomy, Trigger, Update status. User 6.16 VERSION 17 [2010- Jun- 02) (2010-Jun-02) 16 Y.1 drupal-6.12-to-6. 17. patch drupal-6.13-to-6. 17. patch drupal-6.14-to-6. 17. patch drupal-6.15-to-6. 17. patch drupal- 12- to- drupal- 14 to- dru al-6 15-to 6.17 tch drupal- 16- to- 17 patch dru 6.17 16-to-6.17 6.12 dru S.13 DRU pa 6.13 616 17. patch G.14 G.1Z pa G.Ij 6.16 r&lt;i


I'd suggest managing your website directly with CVS. Upgrading then becomes one command:
cvs update -r DRUPAL-6-17

And yes, as you mentioned, Drush is another handy tool.

Hi Rob,

I started out using CVS but switched to using unversioned files because I got a little sick of the overhead when layering SVN. Versioning all those versioning files took quite a while to run (though it's been a couple years since I've tried that route). Maybe I'll give it another go and run a benchmark against the unversioned version to see what the actual difference is - could be it's just just an artifact from past lame experiences.

Thanks for the thoughts, cheers!

When the site is stored in svn then a cvs or drush update isn't always convenient though.

Chris, after trying SVN for versioning Drupal files, I was really annoyed with the way SVN manages folders. If you want to upgrade a module to a newer version, you can't just delete the old folder and replace with the new one as the old folder contains .svn folder deleting which SVN cries errors. Git really made it easy as you can upgrade the usual way (remove and replace) and then commit, GIT fould only think that many files has been modified and commit effortlessly. So, try Git, you will like it.

Ooh, I like the sound of replacing out folders without having to use four commands to do it, and I was wondering what GIT would be like for this process. I assume that just like other version control systems, you can't layer multiple checkouts on top of one another, right? If so, then when Drupal moves to GIT we would have to use a different system. It would be lame to touch the greatness only to have it be taken away. ;) I will give it a try, though. I'm a little late, but am finally starting to work with GIT and am really liking it. Cheers!

It looks like the page with all patches has a new url:

Is there a way to patch when on shared hosting when you don't have command line access?

I don't think so. Any solution I can think of besides the straightforward command-line version just wraps around the command line. All the shared hosts I've used allow for shell access when you ask, though. That might be worth a shot.

Actually, there is a better way.

In this article you will find a script attached that will automate the process for you. It downloads the current version, and the new version, creates a patch from them, and then does a dry-run on it. After you review the changes, you can press "y" and it will be applied.

This way, there is no need to maintain any patch files or download them from anywhere. They are created for you on demand.

Hey, thanks Kalid, that's awesome. I've updated the post to mention this as an option. Cheers!

That's a cool script! I want to note though it does the downloads every time you run it. When upgrading many Drupal installation it may be more convenient to create or download a patch once.

sadadadw thank you very much!