Updating Drupal site code via the command line

Here are steps I use to update Drupal site code to the latest core and contrib module versions. This can be done via the command line using drush.

Doing 'drush up' (all by itself) is popular to update the site code but I don't use it. I suppose if you have a *very* simple site with very few modules that are all using pretty recent stable releases, then it is fine. But, I almost never deal with sites like that (except for simple test sites).

More typically, sites will have development versions of contributed modules or modules that shouldn't be updated for some reason and doing 'drush up' can't be used without qualifying what explicitly needs to be updated. For this reason, I use 'drush up [project]' (or 'drush upc [project]') rather than just 'drush up'.

1) Backup database and files directory

To back up entire site (db+files+code), you can use:

> drush archive-dump

Here's a tutorial on using archive-dump and archive-restore:
http://d.danylevskyi.com/node/1

To just back up the database, you can use:

> drush sql-dump

To zip up the files, you can:

> tar czvf site_files_backup.tgz [path/to/files]

Note: I haven't seen a command for zipping up files via drush though you can create your own drush commands. I use my own scripts to tar up the files (and also for backing up the database).

2) Make sure your repository is ready

Before you start your update, make sure your repository is ready for updates. Resolve any issues before proceeding.

> git status

3) Tag repository and keep note of tag


> git tag [tag-name]
> git push --tags

4) Update Drupal core only

I like to update core separately from contributed modules.

> drush up drupal

or


> drush upc drupal
> drush updatedb

If you don't want drush to backup the code first (which isn't really necessary when using a code repository), then you can use:

> drush up --no-backup drupal

or


> drush upc --no-backup drupal
> drush updatedb

You can also use the --no-backup option if you have an error that shows up that is unrelated to your update. Otherwise, the update will roll back if it encounters errors.

5) Apply patches if necessary

If you have any patches that need to be applied, apply them, e.g.

> cd [project]
> patch -p1 < [patch-file]

6) Test your site

Click around and make sure all is well, and check your error log at:

[yourdomain]/admin/reports/dblog

7) Research any errors

If you are getting an error, there might be a patch available to fix it so search for your error via Google or your search engine of choice. If you find a patch, try it out and see if it fixes the problem. If it does, make sure to marked the issue RTBC (if not already) and leave a comment that it fixes your issue. If not, mark the issue as "Needs work" and leave a comment that explains the patch does not fix the issue. In both cases, provide any details you can so the module maintainers and patch contributors have more information to work on the issue.

8) Revert if necessary

If something is wrong and can't be fixed with a patch, revert your site using the tag and backups you just made.

9) Backup site and tag again

If all is well, backup the database and files again. Then commit the changes to repository and tag repository again.

> cd [project]
> git status (to see what files have been changed)
> git add [files] (to add new files)
> git commit .gitignore .htaccess *
> git push
> git tag [tag-name]
> git push --tags

10) Update contrib modules one-by-one or in batches

I don't update all modules at once because typically there are some modules that should not be updated because development versions are being used or custom patches have been applied.

It is a good idea to check the release notes of a module before updating to see if there are any significant changes that require extra testing.

You can update each module and test/backup/commit/tag in between each update (time consuming) or you can update batches of modules (easier). If there are modules that might cause problems, those should be updated separately (and last).

> drush upc [module1] [module2] [module3]

Then apply patches if needed and run the database update, e.g

> drush updatedb

This works for theme updates too, e.g.

> drush up [module1] [theme1] [module2]

or


> drush upc [module1] [theme1] [module2]
> drush updatedb

11) Repeat steps 6 to 9

* Test your site
* Research any errors
* Revert if necessary
* Backup site and tag again

12) Repeat 10 and 11 as needed

If you have a favorite shortcut or method for updating your Drupal code, leave a comment :)

Comments

Updating Drupal presentation

Hi Kristen,

As luck would have it, I ran across your blog post on Drupal Planet just as I was writing up a presentation on how to update Drupal. My presentation is here :

http://luhman.org/blog/2012/08/21/how-update-drupal

I was pleased to see your post generally "validated" my thinking on this. In other words, use Drush for the update.

A couple notes on your post.

First, you indicate using "drush up" followed by "drush updatedb". I think the first command should be "drush upc" as "drush up" will do a code update AND a database update. http://drush.ws/#pm-update

Second, I think I'd prefer this update sequence :

1) Update modules only

2) Update Drupal core only

3) Try to update modules one final time

Any thoughts on this?

Cool

That's a great presentation... you have some steps in there that I didn't include above like checking the modules that need to be updated.

As for the ordering, I typically do:

1) core

2) less-risky module updates

3) more-risky module updates

since I like to go from less risky to more risky. I don't have any specific reason for this but it just feels like a good ordering to me ;) I lump core as least risky since it probably has more test coverage and eyes looking at it than most modules.

You are right about the 'up' vs 'upc'... though I vaguely remembering drush telling me to run 'updatedb' after running 'up'... strange! I'll update the post soon.

Thanks!

Post new comment - ALL COMMENTS ARE MODERATED - SPAM WILL BE DELETED!

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

I'm a Speaker at DrupalCon Austin

I'm a Speaker at DrupalCon Portland