Update Drupal Core

Last updated May 5, 2013. Created by chiragjain on March 22, 2012.
Edited by siruguri, talvi, shamio, laura s. Log in to edit this page.

For the most complete documentation for upgrading an existing Drupal site, see http://drupal.org/upgrade.

Instructions on how to update Drupal core with a newer version of Drupal of the same category or same base version [ ie Drupal 6/7/8]

Make a backup of your Drupal instance. (For ex: with MySQL)
Download the latest release of your current Drupal version.
Extract the [tar ball or zip] Drupal package.
Set your site on maintenance mode (For ex: How on D7)
Delete all the files & folders inside your original Drupal instance except for /sites folder and any custom files you added elsewhere.
Copy all the folders and files except /sites from inside the extracted Drupal package [tar ball or zip package] into your original Drupal instance.
If the update release includes changes to settings.php replace old settings.php in .../sites/default/ with the new one, and edit site-specific entries (eg database name, user, and password)
If you modified files such as .htaccess or robots.txt re-apply those changes to the new files.
Login to your site as administrator or as user no 1
Run update.php by navigating to http://...yourdrupalsitename/update.php
Follow the process to update your Drupal instance
Disable maintenance mode

Comments

Don't forget themes!

Posted by axon-obriend on May 15, 2012 at 1:12pm

Just did an upgrade to 6.26 using these quick instructions and they don't mention keeping any custom themes that were installed.

Custom themes

Posted by AgnesCB on May 18, 2012 at 6:44am

Custom themes should have been installed under sites/all/themes so that they get preserved in the sites folder (step 5, delete everything except the sites folder) during the upgrade.

Just like custom modules.

Custom themes and modules

Posted by SQSBMedia on May 24, 2012 at 1:26pm

I think there might be some disconnect. I have loaded my modules and themes directly into the themes and modules folders as instructed by those project pages and by proxy the assumption that that is how it should be done. Could you please provide an example of how to rectify this without wreaking havoc on our site? If I just move those modules to the sites folder now will it break paths and therefore break the site? Please advise as I need to perform an upgrade but do not want to lose any information in the process.

Thanks!

For future reference

Posted by jgrubb on January 4, 2013 at 7:26pm

This is everyone's first Drupal mistake, and this will be fixed in Drupal 8, but for Drupal 7 and below modules and themes do not belong in the /modules and /themes directories. The standard place to put modules and themes is in sites/all/modules and sites/all/themes. The reason for this is that it keeps all customizations to your Drupal site limited to the sites/ directory. This makes it a lot easier to update/upgrade Drupal core via the method above. Otherwise you have core modules and contributed modules all mixed together and it gets a lot more confusing.

If you find yourself in the same situation as the comment above, all you have to do is -

1. Disable all of your contributed modules and themes. That means everything that's not listed under the "Core" category on the module admin page.

2. Place them in the correct place - sites/all/modules and sites/all/themes. Create these directories if they don't already exist.

3. Refresh the modules admin page so that Drupal will pick up the modules in their new location.

4. Reenable the contributed modules and themes that you disabled in step 1.

5. Carry on with the rest of the Drupal core upgrade process.

In Drupal 8, this longstanding point of confusion for new Drupal users will be fixed and contributed modules and themes will go where it appears to the new user that they should - modules/ and themes/.

john

Hi John, I was wondering: if

Posted by Castus on March 6, 2013 at 10:27pm

Hi John,

I was wondering: if you disable the modules and move the files, will your preferences/configuration of those modules remain? Or will they be reset?

Thanks in advance!

The config will remain as it

Posted by Formeo on April 6, 2013 at 9:00pm

The config will remain as it is stored in the database, not in the filesystem.

Robots.txt

Posted by vlaarjos on May 22, 2012 at 3:58pm

People also might want to preserve the robots.txt from root folder if it has been customised.

Preserve Custom Files

Posted by mark_johnson on June 27, 2012 at 1:58pm

In addition, you may want to preserve the .htaccess file or other files that have custom code in them specific to your site/server.

Preserve Custom Files - favicon.ico

Posted by sfbob on August 2, 2012 at 5:13am

also favicon.ico if you have one and your installation is in the website root directory

Thank you!

Posted by rudyard55 on August 5, 2012 at 5:35pm

Plain language instructions! So rare! Thank you!!!

I second that!

Posted by The Slave's Dream on January 7, 2013 at 8:41pm

Lots of lovely green ticks on my admin page now - thank-you :)

The ache for home lives in all of us, the safe place where we can go as we are and not be questioned. It impels mighty ambitions and dangerous capers.

Does order matter when modules and core need updating?

Posted by aatkinson on August 29, 2012 at 12:46pm

I need to update my drupal 7 site - both core drupal plus a number of modules.
Is there any advice on what should be performed first (core then the modules, or modules then core)?

Thanks
-Andrew

I'm not sure if there's a

Posted by Chasen on September 6, 2012 at 4:48am

I'm not sure if there's a specific order (as I've done both without issue) but I usually do core first, just in case an individual module has been updated in response to a change in the core code (such as a security patch or something like that).

Generally I:

enter maintenance mode
do a backup
update core (using the instructions above except I usually preserve code in robots.txt and also .htaccess and import them into the new files)
run update.php and flush caches
do another backup
install the module updates (if there's more than 5 or so modules to update, I usually break them up into smaller batches doing backups in between - 95% of the time it's not needed but for a few extra seconds it has saved me huge hassles in the past
run update.php and flush caches
run cron and do a status check
do a final backup and then take website back live

Best Practice?

Posted by okiaer on November 24, 2012 at 9:53am

If I follow the instructions shown in this article the site is down when I delete the old files and upload the new.

If I don't want the site to be down but inly show the maintenance page when upgrading, what is the best practice?
(The files are gone when you upgrade, between delete and upload...)

Instead of deleting

Posted by peterohman on December 21, 2012 at 10:38am

I suggest you modify the step 5 to: create a new directory in the root with the name drupal-old, and move all the files & folders inside your original Drupal instance except for /sites folder and any custom files you added elsewhere into it. Then add a step 13: When you have checked that the updated version works as expected, you can delete the directory drupal-old. Otherwise you can probably find the files you should have kept in this directory, and move them into the updated core...
/Peter

How to Update Drupal Core With Drush

Posted by vulfox on December 28, 2012 at 9:51am

How to update Drupal core with Drush

(Drush is a command line tool for Drupal).

1. Backup everything (all files, databases, etc)

2. Put your site in maintenance mode

Either from Drupal interface or with drush:
(commands for Drupal 7)
drush vset --always-set maintenance_mode 0
drush cache-clear all

3. Save your .htaccess-file, robots.txt and favicon.ico somewhere

...If you have modified them

4. Update Drupal with drush

drush up drupal

5. Check that everything works

Go around your site and test everyhting!

6. Put your site online again

Take your site away from maintenance mode either from Drupal interface or with drush (command for Drupal 7)
drush vset --always-set maintenance_mode 0
drush cache-clear all

Drush command for taking site offline

Posted by okcool on December 28, 2012 at 11:35pm

In step 2 the command to put the site in maintenance mode should be:

drush vset --always-set maintenance_mode 1

shouldn't it?

Correct

Posted by jgrubb on January 4, 2013 at 7:31pm

Maintenance mode is 1 for on and 0 for off.

john

odd drush 'not allowed to store backups...' error message

Posted by jbarchuk on January 28, 2013 at 6:52pm

Rather than just 'asking the Q' I'm going to add a lot of details just in case they make a difference, and so it's all in the record. The drush error I receive returns *exactly* *one* hit via google, so it is obviously not common, and I'm doing something different/weird as regards setup or execution. I'm also new to drush which is the main reason debugging is not intuitively obvious.

This is all under OpenBSD 5.1 but handrolled Drupal *not* the OBSD distribution.

Trying to upgrade Drupal 7.15 to 7.19. Drush is brand new install from drush-7.x-5.8.tar.gz.

I'm not typing at the server kbd but managing via LAN and PuTTY.

I'm logged in as a vanilla user who owns /home/[user] and /var/www/htdocs/[user]

Drush resides in /home/[user]/drush, and that is EXPORTed to PATH.

The trick here is that tutorials like this often don't mention where the user needs to cd to to make things 'work.' It took only one try not being in the webroot to figure out that I need to cd to the site webroot for drush to be able to 'find' the drupal install.

Drush works fine, which is awesome, turns maintenance on and off as described above, so I know I'm in the right place for that.

'drush up drupal' first returns the version status of drupal and modules, and that core needs update. (I just did a couple of module updates manually before I decided to try drush for the core.)

But, and this is the Q :) after the core WARNING and 'Do you really want to continue' and pressing 'y' I receive 'It's not allowed to store backups inside the Drupal root directory.' So, it appears drush doesn't like me being here, or there's some other configuration item I need to set to 'store backups' elsewhere. It's that error message that (via google) appears nowhere else on the net except for the drupalcode.org source page.

It's possible that typing at the server kbd, or logging in as root, or something else might make the error message not happen, but there ought to be another -better- fix. With this level of -critical- function, core upgrade, I'd rather ask the Q here rather than bounce around trying random things.

TYVMIA

jim barchuk
jb@jbarchuk.com

We have to delete existing

Posted by midek on January 6, 2013 at 5:51am

We have to delete existing modules from our server?
This seems like a disaster waiting to happen.

No

Posted by darksnow on January 22, 2013 at 10:30pm

You don't need to delete existing modules from the server, as stated above, all modules should live in sites/all/modules and as such will me preserved as the instructions say to leave the sites folder intact.

Drupal Beginner at http://www.darksnow.net
Web Master of the UK Snowboarding community at http://www.darksnow.co.uk

If you installed Drupal in another language

Posted by catarinavclemente on January 29, 2013 at 12:40pm

Before step 9, don't forget to upload the translation file into yoursite/profiles/default/translations.

catarinavclemente@drupal-pt.org
http://twitter.com/#!/cvclemente

Contributed Modules

Posted by tm541 on February 25, 2013 at 6:45pm

In the update text of the drupal core file it says to, "Disable all custom and contributed modules." before updating core. In your instructions here you do not mention that part. Is it no longer necessary to do this when updating from 6.26 to 6.28?