The following is from upgrade.txt and is also confirmed in the onsite docs.
5. Disable all custom and contributed modules.

6. Remove all old files and directories from the Drupal installation directory.

7. Unpack the new files and directories into the Drupal installation directory.

Just to go from 6.10 to 6.13 I have to do all this. Maybe I am misunderstanding, but "Remove all old files and directories from the Drupal installation directory." to me means remove my entire Drupal installation? Yikes?!!!

Even disabling every module I have installed will take for ever and a day! How often are these updates? I just installed Drupal a few weeks ago and already all this stuff to do?

Help me understand this please!

TIA
Anil

Comments

nikitas’s picture

to.i've used modules like fck editor and it takes like forever just for a module to r-enable it.

Magnity’s picture

In general, it is ok in practice to simply overwrite all files and folders except the 'sites' folder - without disabling any modules.

However - it is essential if you do this sort of thing to BACKUP your site just in case something goes wrong.

Also - bear in mind if you have made any modifications to the .htaccess etc. I generally don't overwrite that one.

Minor updates to drupal core are issued as and when the need arises... only when there is a security update needed. If you don't want to update at all - there is normally a patch provided as well which would secure your site.

dreamgear’s picture

Is it possible to prepare a reasonable working set of upgrade instructions? See also my note below which points out two obvious logical inconsistencies in the existing document.

Magnity’s picture

Even though there are these shortcuts available that will work most of the time, from the point of view of having instructions which always work for everyone, the documented instructions are the best. They may take longer, but they help to ensure that nothing goes wrong. As you get more experienced with your Drupal sites, you will start to learn which shortcuts you can safely apply.

ishmael-sanchez’s picture

The inconsistencies are a result of the fact that there is no distinction between minor and major upgrades. For minor module and core upgrades I don't think it's necessary to disable all modules before you upgrade, but double check the release notes and as always make back ups.

For major upgrades (Drupal 5 to 6) then yeah you should disable the module before you upgrade and you might have to run update.php more than once.

jrcannon’s picture

The current version on the site is Drupal core 6.16 and today it says it needs an update to 6.19. When I read the instructions they are scary and I'm afraid of losing my template and content. It talks about deleting everything and installing and everything, but your post makes it sound easy, like all I need to do is upload the update files over the old ones (except for sites) without the whole convoluted craziness. Is it really that easy? Do you still need to run install.php?

Justin

rikimaru0007’s picture

I'm still in 6.10 and our site have huge contents. I try hard to do Minor Update but still I came up with blank page.
Like uploading all (6.19 folder except *sites*, *modules*, .htaccess, settings.php)
http://www.worx.com.ph (6.10)

I started http://www.computerparts.com.ph (drupal 6.19) and I experiment our theme in worx.com.ph (6.10) to computerparts.com (6.19) and I found out that our theme is incompatible to 6.19
so I have no choice that's why I'm still in 6.10.

That's really craziness especially if you have a lots of modifications in core module root folder.

I follow all instruction like *Site-Offline*, *Turn off all Contributed Modules* and then run update.php
Nothing happens blank page. I also encounter to use this special link
http://www.worx.com.ph/?q=user/login (when I accidentally logout or clear browser cache in Site-Offline mode)

But if your site have few contents re-install drupal with latest version =)

Michelle’s picture

Please do not advise people to not install the security updates. Anyone who takes your advice is leaving their site vulnerable to known security flaws. That's just insanity.

The instructions that come with Drupal, unfortunately, are aimed at major upgrades (ie: Drupal 6 to Drupal 7). I don't know why they don't have instructions for minor upgrades, perhaps just no one has taken the time to file an issue.

At any rate, minor updates do not require disabling modules or any of that. All you need to do is empty out your root Drupal folder except for sites (and files if you have that at the root). If you've installed something that has you copy stuff to misc, watch out for that as well. Then copy the stuff from the tarball except for sites. Pay attention to the release notes to know if there are any changes to .htaccess pr settings.php that you need to be aware of. Then run update.php.

Make sure you back up your site and your database first and then you can roll back if anything goes wrong. The Backup & Migrate module can help with this.

Michelle

jrcannon’s picture

Hello,

I originally installed Drupal into my main "public_html" folder. In the instructions to empty out the root Drupal folder I don't know what is Drupal and what is connected with my hosting and other stuff. For example, there is a folder called "#phpMyAdmin" and I don't think that's Drupal. That's just one example. Is there some way to find out what in that directory should be deleted? Do I really have to delete everything in the folder, or can I just upload the new files over the old ones, and it will replace them when they are duplicate???

Or, better yet, is there anyone who has done the 6.16 to 6.19 upgrade who could help me? This is for a nonprofit, ministry website.

Justin

Michelle’s picture

To be honest, I don't empty the directory first. I don't suggest that, because it _can_ bite you in the but if files are removed. But that's unlikely in a point release. I know what I'm doing enough to chance it. YMMV. :)

What I do is untar the drupal release at the same level as my site. For you that would mean save it above public_html and then untar. Then I go in to the release dir and do an ls. I type cp -R and then highlight everything except sites. Then I right click to paste it in. Then I type ../my-site-directory and hit enter. This copies over everything except sites/ and .htaccess.

Michelle

rikimaru0007’s picture

minor updates do not require disabling modules or any of that. All you need to do is empty out your root Drupal folder except for sites (and files if you have that at the root).

How bout the Module root folder (not sites/all/*module*)?
I have lots of modification there.
Do 6.19 updates contain new modification in *Module* folder? I don't have much time to check it one by one...

Me too I uploaded all 6.19 folder except *Sites* and .htaccess and run update.php but still blank page hahaha...

(^_^) I hope someone create minor update guide

Michelle’s picture

Well, you're not supposed to have any modifications in there. If you don't follow best practices, you're going to have more headaches at update time. No guide is going to get around that.

Michelle

Steven_Bradford’s picture

That's very helpful to know that. It's very frustrating for people who are only maintaining a few sites or even one site, and arent' super experts at this like myself, to slog through the very confusing instructions, which often seem intent on scaring people from upgrading, for fear of causing their site to go down.

I don't understand how you could have said this takes only two minutes though. How do you make sure you don't delete your contributed modules from your modules folder, for example? There's a lot to keep track of, it's not just transferring one file to make an update. You said empty out everything except sites-- but if you empty modules, then all your modules are gone, and must be reinstalled too, right?

I've heard that 7 will address this, but I fear that easier upgrading will be left out, in favor of "cool" features that the pros care more about.

As I reach the end of this email, and think of more problems with upgrading, I think I'm going to leave everything alone. I've got two sites at 6.10 and A new site I installed only a week ago at 6.17. There seems to be nothing but potential problems that have to be unraveled if I do the updates. In other words, fixing something that ain't broke.

Michelle’s picture

You don't put contributed modules in the modules folder. Generally speaking, everything that is changed on your site should be under the sites/ directory. Contributed modules (generally; multisite changes this) go in sites/all/modules. Contributed themes in sites/all/themes. If you've upgraded a D5 site like I have, you may have Files at the Drupal root. In D6 I believe that's been moved to sites/default/files. A few modules need you to put something in Misc (jquery update, I believe, maybe others) so you'll need to watch that.

If you go mixing modifications into core directories or, worse, hack core, your upgrade experience will be much harder. Keep everything in Sites/* and it's pretty easy.

As far as not fixing something that isn't broke, I consider leaving my site vulnerable to known security issues to be very broken. This isn't unknown "maybe" something wrong. This is stuff that we know is insecure and the bad guys do, too.

Michelle

rikimaru0007’s picture

There seems to be nothing but potential problems that have to be unraveled if I do the updates. In other words, fixing something that ain't broke.

Wow! That was a good point. That's why I always check the release notes.

It's like an update from mozilla firefox browser, Sometimes you need to stay in old version if it is not stable (i.e flash player or the plugin-container.exe issue).

robives’s picture

I'm in the process of re-writing my website. After many options it has come down to a choice between Drupal and Wordpress. I was leaning towards Drupal but:
I have exactly the same problem as Anil, it is so complicated and time consuming keeping Drupal up to date. In WordPress you simply click the update button and it gets on with it.
Really, the hassle of doing manual updates is a deal breaker for me. I'm more than likely moving to WordPress.

Quint’s picture

Yeah, I'm jumping ship. I've got about half my sites converted to Wordpress. I just can't take it anymore. I've begun to dread Drupal emails: _"SURPRISE, There's a new update to core, and you have to drop everything and spend most of a day upgrading your sites, or be open to attack._" ... Oh god!, not again. I have plenty of other stuff to do.

Upgrading Wordpress takes literally 30 seconds, with no stress at all. And even in Wordpress (and Firefox, too), I've learned to keep the modules and plug-ins to a bare minimum -- nothing like a module not being ready for the latest core version, or even being abandoned; then you're blocked from upgrading core.

I heard a rumor that there is supposed to be greatly-simplified upgrading in Drupal 7, similar to Wordpress'es. Is it true?

Michelle’s picture

Minor core updates take like 2 minutes per site. Maybe not 30 seconds but it's really not that hard. Just copy over some files and run update.php.

There's some new plugin manager in 7 that's supposed to make things easier but I haven't looked at it, yet.

Michelle

jrdixey’s picture

Hi Quint,

If you haven't jumped ship quite yet - and you're comfortable with the command line and have ssh access to your server - take a look at Drush. Downloading and running updates (as well as new modules) is much faster from the command line. (I won't say "easier" because not everyone is happy with a $ prompt as an interface! But it is indeed faster.)

Good luck,
Jennifer

James Marks’s picture

It's important to understand that, with the standard Drupal setup, all site-specific non-core files — contributed modules, contributed themes, any admin- or user-uploaded files, etc. — should reside within the sites directory within the drupal root directory. If your site isn't set up that way then you should change it so that it is.

If you have Drupal configured in this way and haven't hacked core, performing a minor Drupal core update shouldn't, as Michelle said, take more than a few minutes from start to finish.

The following assumes

  1. you have a functional installation of Drupal in its own directory in the webserver document root,
  2. you haven't modified any core files, and
  3. you haven't modified any .htaccess files. (The update method described below will overwrite existing .htaccess files.)

Begin with a standard Drupal installation

To add and use contributed modules and themes with a standard Drupal installation, start in the drupal root directory and navigate to 'sites/all'.

cd sites/all

(On my machine this would be '/var/www/html/drupal/sites/all'.)

Create a directory named 'modules'

mkdir modules

Create a directory named 'themes'

mkdir themes

At this point, you should have, within your drupal directory,

  1. 'sites/all/modules' and
  2. 'sites/all/themes'.

(On my machine, that would be '/var/www/html/drupal/sites/all/modules' and '/var/www/html/drupal/sites/all/themes'.)

Next,

  1. install all contributed modules into 'sites/all/modules' and
  2. install all contributed themes into 'sites/all/themes'.

If you currently have any contributed modules or themes that are not in the directories described above, create the directories as necessary and move your contributed modules and themes into them (although this may necessitate changing stored paths in contributed modules' configuration settings).

When it's time to do a minor Drupal core update

  1. Put your site into maintenance mode
  2. Make a backup your database (using your username, database name and password)
    mysqldump -u mysqlusername -p drupaldatabasename > drupaldatabasebackupname.sql
    
  3. Make a backup your settings.php file (located in 'sites/default/settings.php')
    cp /path/to/drupal/sites/default/settings.php /path/to/your/backup/copy/of/settings.php
    
  4. Optional: Copy all files in the Drupal root directory into a backup Drupal directory. (This is to allow you to recover if anything goes unexpectedly wrong. Under normal circumstances you shouldn't need to use these backup files.)
    cp -r /path/to/drupal/* /path/to/backup/drupal/
    

    (If you have a lot of modules, themes and/or uploaded files, this can take a while.)

  5. Upload and untar the updated Drupal tarball onto your webserver outside of your Drupal root directory and enter the following on the command line using your actual path information: (Note: the following command will overwrite existing .htaccess files! This will also overwrite all core files causing any user-modifications to be lost!)
    cp -r /path/to/updated/drupal/* /path/to/current/drupal/
    

    This will recursively copy all files in the updated version over the files in the current version. Any files in the current version that aren't in the updated version (all contributed modules, themes, etc... in sites/all) will remain untouched.

  6. Copy the backup of your settings.php file over the new settings.php file in your drupal installation:
    cp /path/to/your/backup/copy/of/settings.php /path/to/drupal/sites/default/
    
  7. Run update.php to update your site
  8. Take your site out of maintenance mode

As long as you haven't hacked core, the entire update process shouldn't take more than a couple of minutes from start to finish and you'll be good to go.

James

Michelle’s picture

The only thing I'd add is that copying over the top of an installation won't remove files that have been removed from the tarball. It is extremely unlikely that a whole file will be removed during a minor update but you need to at least be aware that this method will fail if one is. This is far more likely to happen in contrib, so I always rm -rf the old module directory before untarring when updating a contrib module.

Michelle

James Marks’s picture

The only thing I'd add is that copying over the top of an installation won't remove files that have been removed from the tarball.

True. I use a tool I wrote that recursively compares the current module with the updated module and allows me to identify any differences between the two and allows me to indicate whether I want those 'extra' files to be deleted or left in place (as in the case of added third-party files needed for the module to function) then updates the module appropriately for me. I'll see if I can polish that tool for general use and post it somewhere.

I always rm -rf the old module directory before untarring when updating a contrib module.

The danger in that is that sometimes a current module contains third-party files that are needed for the module to function but aren't included in the updated module tarball. (Apache Solr, for example, needs to have the 'SolrPhpClient' installed for it to work but that isn't included in the Apache Solr module.) One solution is to untar the updated module and then recursively diff the current and updated module directories to see if there are any differences between the two:

diff -r /path/to/updated/module /path/to/current/module

If there are no differences then you can safely 'rm -fr' the current module directory and replace it with the updated one. If there are differences, you can decide whether the additional files are necessary for the module to function and, if so, copy them to the updated module directory then execute the 'rm -fr' on the current module directory.

I should add that if you're not familiar with 'rm -fr' you should be very cautious about using it as it will silently, recursively and unrecoverably remove the target directory and all its contents.

James

Michelle’s picture

Yeah, modules that make you stick stuff in them I treat as patched modules. It's a pain and I wish more modules would let you put needed additions in a separate place.

Michelle

lyndb’s picture

Thanks, James. Very nice write-up!

Weka’s picture

Thank you James and Michelle for clarifying the instructions.
The UPGRADE.txt and handbook pages insist on disabling all custom and contributed modules.
I see you chose not to include this step in your guide. Under what circumstances would you say it would be necessary to turn off all non-core modules during a minor drupal core update?

Michelle’s picture

I've never done that. Those instructions are for major version upgrades where you need to get new versions of the modules compatible with the new major version.

Michelle