upgrade.php fails - keep getting "function.reset"

By iedude@remote.insidetheie.com on 17 Sep 2006 at 08:12 UTC

I've been trying for hours, searching, trying and searching more and I'm about to pull my hair out!

i'm trying to upgrade from 4.6.5 to 4.7.3 - every time i run update.php (from 129) the progress bar jumps to 100% and nothing happens.
If i do a fresh install, with a new (blank) database, it runs fine. but when trying to update against my 4.6.5 database i get the error (above) when running update.php.
When i look in my watchdog table, i see the following:
reset() [ a href='function.reset'>function.reset]: Passed variable is not an array or object in /hermes/web23/b342/account/htdocs/update.php on line 404.

any help or suggestions are VERY welcome.

Comments

after 20 hrs of no sleep, i worked around it

iedude@remote.insidetheie.com commented 17 September 2006 at 23:21

i ended up rebuilding the site completely, all the way from 4.65, to 4.69, then to 4.73 - the root of my entire problem (look at my previous posts) was a garbled USER table.. i'm not sure, but i think because of that 'no user 0' problem that i read about in other posts..

anyway, after 20 hours i'm 95% back online - i still have some issues, but i will post them separately.

Same problem

sifuhall commented 9 October 2006 at 08:17

I am having the same problem.

Has anyone found a solution for this?

My system update is stuck at 129. I run it an it completes at 100%, however in the logs I see:

reset() [ a href='function.reset'>function.reset]: Passed variable is not an array or object

and when I open update.php again it reports I still need to upgrade 129.

I also had this problem upgrading 5.0 beta and found this worked

lias commented 9 November 2006 at 02:22

I had been using firefox to update and got the same error:

reset() [function.reset]: Passed variable is not an array or object

Then I came across this http://drupal.org/node/49501 which suggested updating using IE instead and suprisingly it worked.

Lsabug

Drupal 5.5 update.php(): Running it in IE as User 1 "works"

mmwebdev commented 15 December 2007 at 20:01

Hi folks,

We have been struggling for weeks with Drupal and Ubercart. We have mainly been using Firefox as our browser, using the FIrebug features to get informtion on our UPS shipping details. After updating our server to PHP 5.2.5 in relation to an Ubercart issue, and ultimately starting from scratch using Ubercart's "UberInstaller", we still had to update an Ubercart module, after which we were told that the database schema was out of date, with instructions to run update.php to fix it. When we went to run update.php (still in Firefox), it would just return us to the home page (see our post at http://drupal.org/node/200460). Not knowing much about update.php, we were thinking it was some sort of transparent process and all was well, until the status report told us the db was still out of date.

We rolled back to the prior version of the module we had replaced, and the "database schema out of date" warning vanished. In our further investigations, we found out that there is indeed a "front page" to update.php that we were never seeing. We were still worried about why update.php did not seem to work for us. We saw the advice above. When we went and ran it in IE, we did finally get to the update.php front page.

Thanks for posting your experiences...

Kim & Chuck

The latest: While drafting the email we just tested it again (on IE!) and unfortunately the behavior on Firefox is duplicated - we click "update.php" and it just takes us to the homepage. Oh well!

Aha! I had this problem and solved it

TurboChef commented 10 January 2007 at 21:56

I couldn't figure out why upgrade.php kept erroring out with a reset() function.reset - then I read this post and decided to try doing the upgrade asw another user with Admin rights. It worked!

In order to do this, you just login as another Admin user, then try to run upgrade.php. It should tell you that access is denied and you should change the access check variable to TRUE, then run it. For me, it worked like a charm.

John @ TurboChef

UPDATE: It came back. IE, Firefox, no matter what I do, I can't get rid of it. Sigh.

IE7 works, Firefox 2.0.0.11 fails

enli commented 27 December 2007 at 09:36

After logging in with user 1, update.php works with IE7, but fails with Firefox 2.0.0.11

First message appearing in updating drupal using Firefox:

An unrecoverable error has occured. You can find the error message below. It is advised to copy it to the clipboard for reference. Please continue to the update summary
An HTTP error 501 occured. update.php?op=do_update

At the following page you got this other message

warning: reset() [function.reset]: Passed variable is not an array or object in /web/htdocs/www.mysite.net/home/update.php on line 523.

The update process was aborted prematurely while running update # in .module. All other errors have been logged. You may need to check the watchdog database table manually.

i have the same problem, and

seralf commented 13 January 2008 at 13:58

i have the same problem, and i've found no way to fix it...

the message is:

"warning: reset() [function.reset]: Passed variable is not an array or object in mySite/home/update.php on line 523.

The update process was aborted prematurely while running update # in .module. All other errors have been logged. You may need to check the watchdog database table manually."

the watchdog table reports:

"reset() [function.reset]: Passed variable is not an array or object in mySite/home/update.php nella riga 523."

any suggestions?

eset() [function.reset], or VALIDATION error

dhrubajyoti commented 15 January 2008 at 19:06

I was facing a lot many Problems.. while installing DRUPAL IN A SITE

THE SIMPLE SOLUTION ID USE IE

DON'T USE FIREFOX

not use Firefox? Nonsense!

libre fan commented 4 March 2008 at 14:01

Really how do you expect libre software not to work with another libre software. this is daft!

I also have this problem.

* warning: reset() [function.reset]: Passed variable is not an array or object in /homepages/xxx/update.php on line 315.
* warning: array_pop() [function.array-pop]: The argument should be an array in /homepages/xxx/update.php on line 315.

The update process was aborted prematurely while running update # in .module. All errors have been logged. You may need to check the watchdog database table manually.

---
Libres-Ailé(e)s (Association for Linux and libre software) (France, Cévennes)

5.5 to 5.6

drusnake commented 18 January 2008 at 16:31

Same error. Have always used IE so using FireFox is NOT the solution for everyone.

The last time I go this error I resolved it by completely wiping the files and database and starting over. I believe, for me at that time (5.4 - 5.5), that it was a webuser permissions issue on the shared hosting I use amplified by my use of DreamWeaver to FTP file etc. I may try tarballing my local tree and using cPanel to extract the files instead of DW.

I would appreciate the sharing of experiences from others who use shared hosting (despite the universe of configuration variants) in resolving this issue.

I recognize that the solution for you may not be the solution for me as the underlying cause(s) manifest as the same/similar symptom(s).

Thanks.

This .htaccess edit works for me...

drusnake commented 24 January 2008 at 01:07

I am on a shared host...

at the bottom of the .htaccess file in the domain root (www.yourdomain.com/.htaccess) I added the following to prod mod_sec to permit the update.php magic:

<IfModule mod_security.c>
                <Files update.php>
                                SecFilterInheritance Off
                </Files>
</IfModule>

Now, update.php completes successfully.

Yay!

Mod Security Considerations

jamm commented 2 February 2008 at 18:30

I just wanted to thank drusnake for posting that code snippet.

I was getting the same error described in this thread while trying to upgrade from 5.5 to 5.7. After reading drusnake's post I checked my mod_security logs and sure enough that was the culprit.

I would like to mention one other thing that might help someone. At first his code wasn't working for me, but after some research I realized it was because we were running different versions of Apache/mod_security.

If you are running Apache 2.x.x/mod_security2 use this slight modification:

<IfModule mod_security2.c>
      <Files update.php>
            SecFilterInheritance Off
      </Files
</IfModule>

One other point to mention is this code can also be put inside your apache/virtual host configuration file instead so it doesn't get wiped out when you upgrade drupal. Just one less thing to have to patch/maintain. But you have to control your own server to do this I believe or at least be able to edit its apache config.

Good luck.

IE7 worked after FF2 failed

gnerdalot commented 29 February 2008 at 03:30

I had the same failures in FF that worked in IE7

"http://example.com/update.php?op=error"

Thank you Enli for the note - worked first time!!

Sadly, first time FF really failed me

Gregg

still failure of update.php

libre fan commented 4 March 2008 at 14:55

Hello,

I tried editing .htaccess then I ran update.php. First edited as Apache 1.3, second as Apache 2. My host: 1&1.
I get the same errors:

* warning: reset() [function.reset]: Passed variable is not an array or object in /homepages/xxx/update.php on line 315.
* warning: array_pop() [function.array-pop]: The argument should be an array in /homepages/xxx/update.php on line 315.

The update process was aborted prematurely while running update # in .module. All errors have been logged. You may need to check the watchdog database table manually.

No use telling me to switch to IE ;-)
---
Libres-Ailé(e)s (Association for Linux and libre software) (France, Cévennes)

[solved] [function.reset] [function.array-pop]

libre fan commented 4 March 2008 at 16:32

Got rid of these errors thanks to:

UPDATE variable SET value = 's:1:"0";' WHERE name= 'site_offline';
DELETE FROM cache WHERE cid = 'variables';

(see handbook, how to login).

In PhpMyAdmin if you've got that, click on your DB in the side panel, then click on the SQL tab in the main panel, then paste the command, and press the Okay or whatever button to launch the command.

I was then able to see the home page and login as usual. then I ran the update.php script: success.

---
Libres-Ailé(e)s (Association for Linux and libre software) (France, Cévennes)

Any help to be hired to solve a like problem with my SQL

psymes commented 3 April 2008 at 19:31

I too ran into such problems with the update script messing up my database

I do not, however, have enough competence to go and fix it. Or to try out fixes like the above mentioned no matter how much I feel tempted to just go ahead and press the buttons.

I should probably post the following question as an inquiry under "Paid Drupal services" but since this is the context I thought I might ask here anyway.

Is there anyone here who can be hired to do analyze and repair the errors?

In any case, I don' think there is any major issue. As far as I can deduct and tell from staring into my phpMyAdmin interface, it seems to be only a few tables that got messed up. The site is essentially up and running but I have some annoying errors affecting my taxonomy categories and filtering that I need to set straight.

Leads and recommendations appreciated

Psymes - www.xray-mag.com

I also get the same errors.

Aren Cambre commented 2 November 2008 at 04:51

DISREGARD. It turns out I was inadvertently running update.php against an old DB that was a Drupal 6 RC test system. This suggests the core problem may be invalid data as suggested previously.

I also get the same errors. The .htaccess change is not meaningful to me because neither module is in use. In fact, if I try it, I get an Apache-generated script error page.

The SQL command makes no difference.

Curiously, if I run update.php, it recommends no updates to any module even though I am loading a 5 database in 6. Running through the update does nothing--appears to run no queries--but still generates the warnings. Below the warnings, I get this error:
The update process was aborted prematurely while running update # in .module. All errors have been logged. You may need to check the watchdog database table manually.

In case it matters, I am running XAMPP on Windows Vista.

"function reset..." update bug: Still happening: 5.7 to 5.15

jim_at_miramontes commented 1 February 2009 at 22:55

If anyone is still keeping track of this thing: I just upgraded a site from 5.7 to 5.15, and got hit with the function reset ... bug, doing the update via both Safari and Firefox/Mac. I tried the update from IE7, and it ran fine.

Insert ironic comment here,
Jim

Upgrading from 5.19 to 6.13

jweowu commented 5 August 2009 at 04:58

I encountered this issue upgrading a site from Drupal 5.19 to Drupal 6.13

Logging in as admin before running update.php was the solution, but I couldn't do that initially.

I had my D5 site and database at one URL, and my D6 site at another, and initially the D6 site had the D6.13 filesystem and a copy of the D5 database.

Because of the URL/hostname change, I wasn't already logged in -- the sessions table entries didn't match -- and I was getting errors but no log in form at /user

The solution was to start my D6 site as an exact copy of the D5 site -- same D5.19 filesystem as well as the same database.

That way I could log in to the site at the D6 URL, make the sessions table happy, and THEN replace the filesystem with D6 and run update.php.

This way, D6 recognised me as the authenticated admin user I had already logged in as.