Update PHP stalls

opegasus's picture

Drupal 7
Update.php stalls site in maintenance mode.

Okay every time I attempt to run the update script the run stalls at the 'apply pending updates' portion of the show.
The site is put (by the PHP) into maintenance mode and that is where it stops.

Here is the flow

1) I get a normal update screen :


2) Pending module (now there are more) :


3) This is the window it hangs on while leaving the site in maintenance mode:


4) Never gets past this point during upgrades ? :


5) The only message I found that may be related is: Notice: Undefined property: stdClass::$cache in DrupalDatabaseCache->prepareItem() (line 399 of /home/organic/mysite.com/includes/cache.inc).


6) I went to edit (or at least look at) the Includes/cache.inc file:

and couldn't see what to edit.



Now with the core update the same line numbers look like:


So what's to edit or do, to get updates moving again? Thoughts...clues?

I followed the trail as far as I could go, Googled...nothing directly related.
I also reuploaded the latest VIEWS module in case that was an original faulty upload...no luck.

Additionally I turned off all site caching, Flushed the cache, ran Cron and same results.

Comments

If you return to the admin

scottrouse's picture

If you return to the admin side of your site and review the Status Report, does it tell you that there are pending database updates required? If you go back to run update.php, do you still see the Views 7301 update as pending?

Sometimes you'll get a nondescript message like this, but the update will still have happened.

If it continues to occur, you could try this suggestion I located:

Now I succeed to eliminate this message without using the patch. On admin/config/development/performance I've just set back 'Minimum cache lifetime' and 'Expiration of cached pages' settings to from the option list, cleared the cache by clicking the button above them, logged out, then back, now it does not appears.

I wouldn't advise editing any of those core files...remember the kittens...but rather try to find the root of the problem.

Your error is probably specific to a certain server configuration rather than a universal problem.

Here's a quick Google tip for getting better results with error messages. You can typically find more results if you remove any parts of the error message that would be specific to your situation (server paths, etc). Take the following error message:

Notice: Undefined property: stdClass::$cache in DrupalDatabaseCache->prepareItem() (line 399 of /home/organic/mysite.com/includes/cache.inc).

I removed the /home/organic/mysite.com part of the message before searching. I also typically truncate off the trailing period (just to be safe) and the Notice: at the beginning. (Here's a link to that Google search.](http://www.google.com/#sclient=psy-ab&hl=en&site=&source=hp&q=Undefined+property%3A+stdClass%3A%3A%24cache+in+DrupalDatabaseCache-%3EprepareItem()+(line+399+of+%2Fincludes%2Fcache.inc)&pbx=1&oq=Undefined+property:+stdClass%3A%3A%24cache+in+DrupalDatabaseCache-%3EprepareItem()+(line+399+of+%2Fincludes%2Fcache.inc)&aq=f&aqi=&aql=&gs_sm=s&gs_upl=559l5238l0l7545l2l0l0l0l0l0l0l0ll0l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=20b14eae256dd96d&biw=1440&bih=784)

The first search result led me to the final Drupal.org issue.

Let me know how that goes.

No joy!

opegasus's picture

Actually we both found basically the same resources, threads.

I tried switching themes (Bartik) disabling the Views Module, Uninstalling the module (at least it was dropped from the update list) and turning off all caching, compression switches.

So far, nothing has worked...I'll keep searching and playing. Thanks Scott, will let you know what I find.

I just saw the one Views

scottrouse's picture

I just saw the one Views update in the list of required updates. Were there others? If not, then no need to run update.php right?

Same-same...

opegasus's picture




This is all the modules requiring an update...this includes the newest core 7 security update.








I have been getting this error...occasionally...






The first four updates

scottrouse's picture

The first four updates (system x1, image x2, and menu x1) are all from the core update (7.12) as you mentioned. It looks like you've tried updating to the latest dev release of core (probably not necessary since the 7.12 release just dropped yesterday), but I understand the search for solutions.

Without looking at the back end of the site, and possibly the database, I'm not sure I have a great answer as to what may be going on. The PHP notice you're seeing may indeed be related, but I can't say for sure.

Thanks I suspected..

opegasus's picture

...that one would need to peel open the database and see the files. I looked at those lines of code/errors but couldn't see anything 'obvious'.

On a somewhat related note. Drupal 6 core updates state to take all contrib modules offline (uninstall them) before a ver upgrade. I have 3 sites in 6 and when I went to update the first one, taking all the modules off (uninstall them) crashed the site and I only got a php error output when going to the Admin/logon page.

Question is, how critical is it to uninstall the modules before updating the core? Also does one actually have to remove the core files before installing the new core files?
The site is being restored from a backup so it's functional but offline until the security is in place.

There's a very important

scottrouse's picture

There's a very important distinction between "disabling" modules and "uninstalling" modules. Previous database update instructions suggested "disabling" contributed modules before updating the database (running update.php). Though few probably follow those instructions faithfully, it may be helpful. However, "uninstalling" your modules would result in a complete loss of any data and configuration related to said module. One would definitely not uninstall modules unless they wanted to remove all data related to that module.

Unchecking the box by a module on the module admin page and submitting the form "disables" modules. To "uninstall" a module, one has to first disable the module, then proceed to the uninstall tab to initiate the uninstall process. Again, don't uninstall modules unless you're ready to remove them completely from your site.

For what it's worth, I don't even disable modules before updating the database...Drupal 6 or 7.

Regarding replacing core files when updating, it's important that no old files are left on the server (in the docroot) or mistakenly merged with new files. It's not required to remove the files first as long as you're sure they're all being replaced properly using whatever method you use to replace them.

Here's a good core update trick. Say all of your site's files are in a "www" directory. Create a new directory at the same level as the www folder with the new files (let's call that directory "www-new"). Copy the contents of www/sites into www-new/sites. Then make www-new your new docroot (either by a simlink trick, if you're into that sort of thing, or just by renaming www to www-old and www-new to www. Again, substitute the name of your server's docroot. This task is clunky, at best, to accomplish via FTP. SSH will make your life much, much better.

One final note. If you want the security benefits of a core upgrade, but are having trouble with the full jump from 7.10 to 7.12, there is a security-fixes-only release (7.11) for just that purpose. Review http://drupal.org/drupal-7.12 and http://drupal.org/node/1173280.

Ouch wrong venacular....

opegasus's picture

....used. Yes I disabled them and did not actually uninstall them. Yes, uninstalling them would certainly be at the cost of all data associated with each module or combination of modules.



Thanks for your experience sharing on the updates. I like the site trick (www and www-old) and yes, I agree using SSH (and as you have demonstrated, Drush) is the way to go with moving/adding/installing files in Drupal. I was just recently granted -root- access so I previously did not have the means to run the old rename/create new/test trick. So today it looks like I get to try that out. So simple, logical. Yes, time consuming but considering the wasted 36 hours, it would have saved me. Plus the site would have been down for a lot less time...which as you know, is key!



I think the D7 issue regarding update-php was pre core updating. The process just hung as depicted originally and seems to be related to the Views upgrade. But, as I mentioned, I did disable and actually uninstalled Views (didn't have anything created in the DB with Views) and attempted the update php again...no joy.
So I get to figure out what I did right around that time. Thanks again Scott for taking the time to answer.

TaDa! Figured it out...simple blunder.

opegasus's picture

Well after much ado, I finally figured it out. It was a simple fix.
I kept getting undefined cache errors...

[Notice: Undefined property: stdClass::$cache in DrupalDatabaseCache->prepareItem() (line 422 of /dir/dir/TheLightScriber.com/includes/cache.inc).]

...and I had no clue where to start, none. I did a whole lot of file stuff, database cache wiping, testing, nothing worked.

Finally I noticed on my SettingsPHP that I had a custom Maintenance page listed and I had noticed on the 'attempted' Update pages the theme was a bit screwy but kept pushing on. Once I set the maintenance theme to a Drupal core theme (Seven) the updates happened flawlessly...and just in time for a security update on one of the installed modules.

I guess I will wait to learn proper maintenance page themeing before I muck with that again!

Many thanks for all the answers and solution suggestions Scott !!!

Western Montana

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week