Questions about upgrade process

By venkat-rk on 8 Apr 2006 at 17:43 UTC

Reading through the 'Upgrading from previous versions' handbook leaves me confused about the following, so I would be really thankful for any answers:

1.) Is running update.php absolutely necesary even when there is no database update? That is, can I just copy over the files and skip running update.php?

2.) Should the following be done *before* backing up the database:
- being logged in as admin?
- turning off all modules except the core ones?

3.) If the answers to No.2 above is yes to both, are those steps also necessary even when there is no database update or they are irrespective of whether or not there is a database update?

Thanks in advance.

Comments

What worked for me

Mojah commented 8 April 2006 at 21:01

I just did an update from RC1 to RC2 on a live site and it worked fine doing the following...

1) Backed up database
2) Logged in as admin
3) Saved a copy of the settings file
4) Uploaded the RC2 files onto the server overwriting exisiting ones
5) Ran update.php even though it said no updates available
6) Logged in and everything seems ok

When updating from earlier versions, I usually do one version to the next version upgrade until I get to the latest version. This may not be the most convenient approach.

I did not disable any modules for any of my upgrades. The update.php is most probably only necessary when there are db changes. In RC2 most of the changes were probably to do with core code patches. Lets wait for one of the programmers to confirm this.

One Love

Thank you, Mojah. I really

venkat-rk commented 9 April 2006 at 02:35

Thank you, Mojah. I really appreciate your thoughtful and detailed reply.

answers

cel4145 commented 9 April 2006 at 02:47

(1) update.php is for updating the database (unless something has changed recently with 4.7)
(2) You can't run update.php unless logged in as admin or you edit the update.php file. It's not possible to run the script. That's why you login.
Yes. It's best to turn off modules in case they have not had the code updated or need a database update themselves. The best practice here is often to get Drupal core working, then worry about updating the contrib modules.

Thanks! So, can I take your

venkat-rk commented 9 April 2006 at 06:51

Thanks!

So, can I take your answers to mean the following?

1.) Running update.php is not necessary unless there are database changes between from one drupal version to another.

2.) Irrespective of whether or not a Drupal upgrade needs a database update (that is, needing to run update.php), it is recommended to login as admin *and* turn off contrib modules before backing up the database in order to make the upgrade process as smooth as possible.

Not certain about 1

cel4145 commented 9 April 2006 at 16:23

I'm not a 100% sure of 1 because I have not tried to do a 4.7 upgrade. But that seemed to be the case in the past.

I'm also not sure I would say "recommended" because you do have to be logged in as admin (or edit the upgrade.php) file in order to run the update script. There are bound to be people that would ignore the recommendation. However, it's hard to say for sure when the advice is taken out of the larger context of the rest of the instructions. It might work.

Thanks for the

venkat-rk commented 9 April 2006 at 16:43

Thanks for the clarifications. I am trying to make some additions to the 'Upgrading from previous versions' handbook, so these will be really useful.

more on module updates

cel4145 commented 10 April 2006 at 00:25

Sounds like you might want to do some more research by posting to this thread. It appears that some modules should be updating themselves through update.php. In that case, modules should be left on, assuming that the site administrator has already updated the code.

Thanks for alerting me to

venkat-rk commented 10 April 2006 at 05:21

Thanks for alerting me to this thread. I will keep it in mind when writing things up.

Here are some answers that

bonobo commented 9 April 2006 at 13:28

Here are some answers that have worked for me. YMMV.

RE 1: If there are no database changes, there is no need to run upgrade.php. Upload the new files, overwriting the old files. In most upgrades (ie, 4.6.x --> 4.6.y), only a few files are affected. If you read the patch, you can figure out exactly the files you need to upload.

RE 2: This is my process, and this assumes you have already backed up the codebase of your original site.
a. back up database.
b. back up settings.php
c. create new database from the backup created in step "a" -- I like to make sure my backups work, but hey, I'm paranoid like that.
d. rename original settings.php to settings.bak
e. edit backup settings.php (created in step b) to point to new database (created in step c)
f. log into site as admin, turn off all modules except core, select bluemarine as the theme, and run the update.php

If you take these steps and the database does not upgrade cleanly, you can get your site back by restoring your original codebase, and editing the settings.php to point to the original database.

If the upgrade is to a different version of the same release (4.6.5 --> 4.6.6), it is not likely that the contrib modules will break during upgrades. Modules that require a patch to core modules (like taxonomy access control) are the exception -- if the upgrade affects the patched core module, you need to be very careful with the upgrade.

If you are upgrading versions (4.6.6 --> 4.7) then the contrib modules you are using will also need to be upgraded. This process will vary widely from module to module.

RE 3: if there is no db upgrade, you don't need to log in as admin, or, technically, back up the database. However, anytime your messing with your site, backing up the database is a good idea. Really, creating backups is *never* a bad thing to do.

Hope this helps.

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

-------
http://www.funnymonkey.com

I honestly didn't expect to

venkat-rk commented 9 April 2006 at 16:45

I honestly didn't expect to have such a detailed response. This is going to help me a great deal not just in upgrading my own sites but also in writing up some stuff for the relevant handbook section.

Thank you very much.

Glad it was helpful, and I'm

bonobo commented 10 April 2006 at 00:44

Glad it was helpful, and I'm glad to hear you're going to be writing this up for the handbook.

I was thinking as I wrote my response that the collected responses to the thread you started would be a nice handbook page.

EDIT: according to the thread cel4145 points out, most of my advice/methodology might be rendered obsolete by the presence of the new install system -- however, as I haven't tried to upgrade using the new install system, I don't know for sure -- I'll probably try it out over the next few weeks, but still rely on upgrading manually (as I described above) on critical sites. END EDIT

Cheers,

Bill

-------
http://www.funnymonkey.com
Tools for Teachers

-------
http://www.funnymonkey.com

peterx commented 10 April 2006 at 05:25

Update 4.7.0 RC1 to RC2: http://drupal.org/node/57815

petermoulding.com/web_architect

Thanks. That was actually

venkat-rk commented 10 April 2006 at 08:16

Thanks. That was actually the thread that got me going on the upgrade attempt:-)

skip intermediate versions

edrupalec commented 19 April 2006 at 19:38

you can't upgrade from 4.5 to 4.7 directly, without upgrading to 4.6.

but you can upgrade from 4.6.6 to 4.7.0rc3, or from 4.7.0b6 to rc2, right? You can skip versions as long as it's the y and not the x in 4.x.y, is that right?
-----
Drupal ecommerce, at www.drupalecommerce.com is a new site written using language that Drupal beginners and intermediate users can understand. Quick links to "Modules."

Why not?

heine commented 19 April 2006 at 20:09

you can't upgrade from 4.5 to 4.7 directly, without upgrading to 4.6.

Why not? Just did it and it went very well.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

previous problems in the past

cel4145 commented 19 April 2006 at 21:18

I can't cite exactly when, but it has been awhile. There have been previous problems in the past with jumping a number of versions at once. Happened to me once.

No reason, though, not to try it.

Hmm

heine commented 19 April 2006 at 21:39

Ah ok, but then this might be 'superstitious behaviour' (skinner); I simply looked at update.php and saw it contained updates since 2004-10-31, the first since 4.5.0 release.

Of course, there's no harm in updating N versions to reach the last, just tedious ;-)
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

It's not that you can't,

sepeck commented 19 April 2006 at 22:17

It's not that you can't, it's that there might be considerations or it will go boom. Between 4.4 and 4.5 you had to manually add some tables. Also, most testing of upgrades is between one version. Contrib module updates may have specific update steps that need to be accomodated. It's not that you can;t, but unless you know your site and Drupal really well, it may lead to problems outside someone's abiltity to deal with.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

Intermediate updates

heine commented 20 April 2006 at 20:01

Yes, I can imagine that modules needing an intermediate update will break a lot... I'm very happy with the new module install / upgrade system :-)
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.