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 :)
- kristen's blog
- 118796 reads
This is a featured content block that has been configured to show blog nodes with terms SEO or Drupal SEO by the author kristen. It shows random list of 20 results in the block and 30 results on the more page.
- Free Google Keyword Research Tool
- Drupal SEO Reviews
- Drupal SEO Modules
- Basic SEO Top 10
- HTML Validation: Free HTML Validator Tools
- Drupal Nofollow Link Sculpting
- BADCamp Drupal SEO Presentation 2009
- 503 HTTP Status Code when Site Down
- Kristen
- Drupal Has Multiple h1 Tags
- Drupal Node Teaser SEO
- Free SEO Tools
- Drupal Pathauto URL Aliases Settings
- Drupal Pathauto Module
- Drupal Meta Tags (nodewords) Module for SEO
- Make Drupal SEO Friendly
- Fix Duplicate Content with Global Redirect Module
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!