By jason342 on

It's advised that update.php should run only once. More than once may cause problems to the database.

Does placing http://www.example.com/update.php in the brower count as running it?

Or what does exactly count as running update.php?

I ask this because the first time I ran the update.php it said I need to configure the settings, so after configuring the setting, I ran it again and this time it was ok.

But did I just run it twice?

As in the fact I placed the update.php in the browser and hit "go", does that count as running it twice, potentially causing problems?

⋅ Categories: Drupal 4.7.x

Comments

karldied’s picture

karldied commented

I also found this confusing. After adding taxonomy access, a contrib module to v5 rc1, I got a log message (www.example.com/admin/logs/status) that update needed to be run promptly. But the text at www.example.com/update.php warns against running it more than once.

I finally decided to hit the "update" button, and it seemed to detect that most the update tasks were already complete, but that one table sql was needed, and it appeared to run only this one.

jason342’s picture

jason342 commented

I think what you talking about is running the "update" that is located in "modules" in administer panel. Which is advised to do whenever a new module is added.

I think that’s different to the upgrade update.php. But i'm not too sure.

My question is about the actual version update, and want to know what constitutes as running update.php twice, or more.

karens’s picture

karens commented

That probably is confusing, especially if you never open up the hidden part of the page to see that it contains a list of all your modules and all their updates, with the next update that is needed automatically selected. The message is not saying that you should not run the update.php page more than once, it's saying you shouldn't run any of those individual updates more than once, which won't happen unless you change the selected values.

You should always run update.php whenever you add new modules or update a module's code with a newer version, and as long as you just leave the automatic selections alone, everything should be fine. If an individual update has already been run, it won't be selected, and nothing will happen.

vm’s picture

vm commented

running update.php from adminsiter modules is same as running update.php from http://www.yoursite.com/update.php

basically it is unneeded to run update.php twice in a row.

you can however:
update drupal = run update.php
update a contrib module = run update.php

it is not advised to:

update drupal = run update.php than run update.php again. it is a warning. provided you didnt adjust any of the drop downs when you ran update.php a second time than nothing was adjusted the second time it ran. so you are ok.

jason342’s picture

jason342 commented

Vm does my case count as running it twice?

I placed the http://www.mysite.com/update.php in the browser then pressed "go", it said I need to configure the settings because I forgot to do it when I done uploaded 4.7.5, so after configuring the setting, I placed the http://www.mysite.com/update.php in the browser again then pressed "go". This time it updated fine.

So does that situation count as running the update twice?

vm’s picture

vm commented

no

jason342’s picture

jason342 commented

So what does count as running an update.php in this instance? When the progress bar shows?

I always thought placing the http://www.mysite.com/update.php in the browser + press 'go' = running update.php.

vm’s picture

vm commented

yes the progress bar must run. calling the update.php page into the browser does not complete the update.php process.
The database is untouched until the update "button" is clicked which is the step prior to seeing the progress bar.

when update.php is called by the browser it has a few jobs to do before the update is actually run.
one of which is to make sure that the proper permissions are met, otherwise anon users who are familiar with drupal could run update.php on a whim.

so just calling update.php into your browser is fine, its actually fulfilling the update script that can be hazardous. The hazard is more from non familiar users messing with the drop down menus and forcing updates that are already done. This should only be done by very advanced users, in the case that they understand what went wrong during an update to either core or to modules.

so to narrow this down a bit. you are ok with calling update.php by your browser more than once. what you don't want to do is click the update form button multiple times in a row.

karldied’s picture

karldied commented

Back to my earlier comment (immediately below the original post), I intended to communicate that I pushed the form button at www.example.com/update.php a second time.

The first time was right after installing 5.x. The next time was a couple days later after installing taxonomy_access v 5.x-dev, following which a message in admin specified to do the update, including a link to update.php. If I remember, after pressing the update button the second time, it gave me the progress bar, seemed to do a check, I think it realized that I had already done the core update to 5.x, and also that the now-installed taxonomy_access module had an update, and ran only that one update. I didn't mess with the drop-down menus.

There may have been a capability to run the v 5.x update for taxonomy_access somewhere else in admin like in "modules" in administer panel, but I didn't see it. -karldied

dkdev’s picture

dkdev commented

This warning is very unnerving to a newbie. Can someone explain what actually goes wrong when you run this (update form) more than once? What does it do to the database to mess it up?

Can't this application be enhanced so that if it does not need to be run (and should not be run), it detects that state and refuses to run? (I imagine that some update instructions are sticking around after they have been applied, and that applying them twice create spurious tables, etc. So, upon applying those instructions, can't they be removed from wherever they are initially stored? This doesn't seem so hard, conceptually.)

If you *do* run it twice, can anything be done (aside from restoring a backup) to correct the situation?

This is like trying to drive a car with only the controls but no visibility out the windshield, or headlights not working at night.

A little transparency can go a long way, especially for admins who are not familiar with the code. If only car mechanics are supposed to drive cars, that limits the effectiveness of cars. Of course, this scenario arises at the very beginning when a newbie is trying to set up the first drupal site. Thus I think it would make sense for this function to be much more newbie-proof. These obstacles tend to send newbies away from the platform, rather than draw them in. Mystery is not very useful in the web admin business, and if there is anything involved that is dangerous, it should be handled by the knowledgeable code, not by the non-knowledgeable user.

Or, make the user more knowledgeable more easily... ;-) Give us the Why in addition to the What, or at least allow us the option to find out the Why in context of the What.

Thanks--

vm’s picture

vm commented

Realistically, nothing. provided you aren't playing with the drop down menus. If you mess with the drop downs and then run update.php again, you will alter your database, and no, there would be no way back except for a back up.

in its most basic form, you can corrupt your database by altering the drop downs to run an older update.
As explained by Karen S in her comment here: http://drupal.org/node/107616#comment-186734

dkdev’s picture

dkdev commented

This is making more sense, especially the point that the update.php does auto-select what it ought to select, and if a particular update has been applied it will no longer select it again, unless a new version (or uninstall) comes along.

Sorry for missing Karen's post in skimming through the earlier replies, sometimes hard to capture the wheat amidst all the chaff, especially if the reference is sort of abstract.

I assume this modules-to-update selection is what you are talking about with the "drop down menus"? (That is, you are referring to update.php's drop down menus, as opposed to any drop down menus on my main web site, if any drupal themes support drop down menus. At this point I am not looking into playing around with any menu formats in the theme I'm using, and Garland does not use drop downs so far as I know.)

But, does update.php automatically de-select the modules it has updated if and when one returns to the initial web page that it presents?

vm’s picture

vm commented

I assume this modules-to-update selection is what you are talking about with the "drop down menus"?

Yes

But, does update.php automatically de-select the modules it has updated if and when one returns to the initial web page that it presents?

The downdowns would shift to no updates available

gmasky’s picture

gmasky commented

I am running Drupal 4.7.0. My hosting company did not provide the update.php file. Can I copy-paste the update.php file from Drupal 4.7.6 into my root directory and run update.php safely?

We have recently upgraded civicrm 1.5 to 1.7 and the civicrm profiles in Drupal user account have disappeared. I reckon I need to run upadate.php

Any advise will be appreciated.

davidteall’s picture

davidteall commented

I am picking up on an old thread and an answer you gave to a question about running update.php. You said "That probably is confusing, especially if you never open up the hidden part of the page to see that it contains a list of all your modules and all their updates" When I run update.php I see no list of modules at all. How do I un-hide this list? (I am running Drupal 5.8)

vm’s picture

vm commented

A) you are using an insecure build of Drupal and should update to 5.10 immediately to protect yourself from publicly known exploits.
B) to expose the list you click on the select versions link above the update button and the collapsed menu expands.

davidteall’s picture

davidteall commented

Thanks. I have updated to 5.10.

In doing so I have re-discovered how the update.php page works. I had forgotten that it is a three-stage process to get as far as the list of modules. Because of the dire warnings on the opening page I had not clicked on the "run the database upgrade script" link. I wonder why on earth is it named in this way? Clicking on it does not run the script - it merely leads to page two of three. The script doesn't actually run until you click on the button at the bottom of page 3. Unless I'm the dimmest user of Drupal in the universe I can't be the only one to have got stuck like this.

Thanks again for your help.