How I update Drupal core

By Erik, Thu, 05/26/2011 - 18:46
When new security releases come out for Drupal, updating is definitely something that you want to do sooner rather than later. My philosophy has generally been to update my local setup immediately, let all of our developers/users know that I am going to update the shared dev server within two days, then schedule a time to update production based on any issues we find with the dev server. Since we run most of our sites as a rather large multisite, it means updating everybody at once, but hey, that's what dev's for, right? Well, we'll leave that for another discussion. Since last night, Drupal 6.21 and Drupal 6.22 were released, I have updated a couple of machines and been asked to help with some more, so I thought it might be nice to have this written down somewhere. The general way I setup Drupal sites is to download Drupal into a version specific directory (eg., drupal-6.20 and drupal-6.22) and the point a generic symlink named "drupal" at the version I want to be current. Then I can set my apache conf (or cpanel or whatever) so that the websites are being driven out of the "drupal" folder. This allows the upgrade process to happen with some fairly straight forward rollback ability if things don't work. And we never have to start/stop apache or reconfigure the conf files. So my directory looks like:
lrwxrwxrwx drupal -> drupal-6.20
drwxr-xr-x drupal-6.20
(that's well stripped down, but hopefully you get the idea). The basic outline of what I do is to:
  1. download the new version of Drupal
  2. backup all of our databases
  3. move the sites directory from the existing drupal-6.20 to the new version
  4. delete the symlink and repoint it at the new version
  5. run update.php on each site in the new multisite
  6. clear caches
The first thing I do is to download the new version next to the existing version, not overwriting:
drush dl drupal-6.22 --drupal-project-rename=drupal-6.22
The drupal-project-rename parameter is necessary because drush wants to rename the folder drupal by default. So now our directory looks like this:
lrwxrwxrwx drupal -> drupal-6.20
drwxr-xr-x drupal-6.20
drwxr-xr-x drupal-6.22
And of course, to be safe, we backup our databases. If you have a working drush setup, you can easily run the following:
drush @sites sql-dump --root=/path/to/drupal --yes --result-file=/path/to/your/drush-dumps/@DATABASE_@DATE.sql
If you have a good place to put sql dump files and know the full path to your Drupal root, drush will go through and dump each file. Next, we want to move the existing sites directory to the new version, but we have to get the new, but empty sites directory out of the way.
rm -rf drupal-6.22/sites; mv drupal/sites drupal-6.22
And remove and repoint the symlink for drupal
rm -f drupal; ln -s drupal-6.22 drupal
As of this point, all of our sites are running on Drupal-6.22. However, if the new version has database changes (as 6.22 did) we need to run update.php on all of the sites. I also tend to clear cache here just because... Luckily, drush makes this easy as well.
drush @sites updb --root=/path/to/drupal --yes
drush @sites cc all --root=/path/to/drupal --yes
If all goes well, we can do the same on dev and then on production. The key here is that if something does go wrong, you can basically reverse the process, put the sites folder back into drupal-6.20, run drush sql-cli < /path/to/that/dump/we/made.sql and repoint the symlink back to the original folder. If you're extra careful, you might even throw in the whole process of turning the site offline, disabling all of your contrib modules, etc. but so far, *fingers crossed*, I haven't needed to do that for minor version upgrades. Or if I do, I find that out on my local machine before blowing up a production system. drush @sites vset site_offline 1 --yes; drush @sites vset site_offline_message "We're upgrading Drupal, be right back." But remember to turn them back on ;-) drush @sites vset site_offline 0 --yes My next approach will be integrating git into this whole process... git pull, git checkout 6.22, drush @sites updb... But not yet. Soon, but not yet.
Keywords

Comments11

Scott Rouse (not verified)

12 years 9 months ago

Erik,

Thanks for this great write-up. Much appreciated.

Regarding the following code:
drush @sites updb --root=/path/to/drupal --yes
drush @sites cc all --root=/path/to/drupal --yes

Does that tell Drush to run the updatedb command on all sites in the multisite install? Do I need to define the sites in a separate conf file for Drush or does it just know from the sites/[sitename] folders?

I'm looking forward to reading about your git upgrade process once you've integrated it.

Thanks,
Scott

Drush has the ability to shortcut the multitude of parameters that you need to pass along on the command line with aliases.

You can see the examples of how to set up aliases in drush/examples/example.aliases.drushrc.php wherever drush is installed.

There are a couple of pre-built aliases (@self, @sites, etc.) that can be used without having specific definitions. @sites runs the command sequentially on each site in your multisite. It's quite safe to test it out with:


drush @sites status

Hope that helps. And it leads me to think that a blog post on aliases and setting up drush nicely might be next in line...

Jennifer B. (not verified)

12 years 9 months ago

I have tried to update my Drupal core from 6.20 to 6.22 and it wont take. All the files in my directory are 6.22 and I have run update, but status report still says running 6.0. Soo strange. Do I need to replace setting.php?
Kindly,
Jennifer

The report says Drupal 6.0? or Drupal 6.20?

You shouldn't need to replace settings.php. Typically that file doesn't exist in core and default.settings.php doesn't change except in rare circumstances.

If you look at system.module line 11 (or so) the version should be defined:


/**
* The current system version.
*/
define('VERSION', '6.22');

UPDATE: There are a couple of other messages about this on the Drupal forums. Hopefully they might help?

davemaxg (not verified)

12 years 9 months ago

Erik, I'm so happy I found this article. I'm struggling through the upgrade and I think I can definitely benefit by your approach. Thanks!

Feel free to let us know how your struggles turn out! There's always a dozen ways to accomplish things in Drupal. Upgrading is no exception to that rule.

gmclelland (not verified)

12 years 8 months ago

Here is a similar technique that I like, but couldn't get to work with drush. Maybe you would know how?

http://horncologne.com/content/nice_server_setup_helps_streamline_upgrades

I've found that symlinks and Drush don't play nicely for some reason... I would be curious to know if you had aliases set up rather than cd'ing into the sites/project directory would work better. The problem seems to be especially with dl and finding Drupal root correctly. I was never able to fully track it down. But that is one of the reasons why I do keep sites in the Drupal root folder and use the symlink only for Apache's sake.

gmclelland (not verified)

12 years 8 months ago

Here's the fix that works with drush, enjoy. http://dudenhofer.com/post/symlink-soup

I tested it and works great. Thanks for all the drupal articles.

Ryan (not verified)

12 years 7 months ago

Thanks for sharing this. It seems like you use the same methods as I do when backing up and updating to a new system. I'm trying to update from Drupal 7 to Drupal 8. I'm having some trouble. It keeps saying something about a DLL messadge.

Mat (not verified)

12 years 6 months ago

In reply to by Ryan (not verified)

"Thanks for sharing this. It seems like you use the same methods as I do when backing up and updating to a new system. I'm trying to update from Drupal 7 to Drupal 8. I'm having some trouble. It keeps saying something about a DLL messadge".

Did you check you tcip or ftp settings. Or possible your firewall?