By bigred on

Hello all,

I would appreciate any help you can give me on this. I just updated from 5.0 RC2 to 5.0, and the site itself looks perfect, however on my admin page there is an alert that says "One or more problems were detected with your Drupal installation. Check the status report for more information."

Following the link, to the status report, I get the error "Database schema Out of date
Some modules have database schema updates to install. You should run the database update script immediately.", however when I run update.php, all I get is a blank screen and the errors do not go away.

Any thoughts on this? I have seen several posts with a similar issue from previous Drupal versions, but no one ever seemed to get an answer. One respondant suggested changing php.ini setting 'max memory allowed for a script to run' (or whatever it's really called) from 8M to 50M. I tried that and it did not resolve the problem.

Thanks in advance,

Brandon

⋅ Categories: Drupal 5.x

Comments

micheleannj’s picture

micheleannj commented

I'm pretty much at a standstill until I can figure this out. I can't find any errors in Drupal or Apache to even try to start debugging this.

Any suggestions or guess more than welcome.

Thanks,
maj

micheleannj’s picture

micheleannj commented

Open up update.php and uncomment-out

ini_set('display_errors', FALSE);

This will dump errors to the browser which should lead you to the problem.

In my case, I screwed up copying the modules directory from my backup and ended up with modules/modules. Other posts about this I've come across suggest that it's often a problem with bad directories in the modules folder so check for anything funny (especially if you are using a version control system or have recently copied things from backups).

Hope this helps someone else...

jurgen’s picture

jurgen commented

When commented the "ini_set('display_errors', FALSE);" line, I suddenly realized what was going on:

During the setup phase, I found that the memory settings (and the script time execution) of my commercial host were not enough; adding these lines to the very beginning of the update.php script worked like a charm:

ini_set('memory_limit', '32M');
ini_set('max_execution_time', '180');

Indeed, the error displayed in the browser referred to "insufficient memory"; after that, the update.php could do its magic and voilá! my database was politely updated.

(it was hard to find but...) XD

gracearoha’s picture

gracearoha commented

I was also having the same problem.

I edited my update.php ini settings as suggested above by jurgen, but am still receiving a blank page when i run update.php.

Anyone have other ideas?

psycho@generalitati.net’s picture

psycho@generalitati.net commented

I'm having the same problem too. Could this problem be caused by the old php version. I know there are some problems with php older than 5.1.2 at xml feeds module....
I'm using the 4.4.4 php version.

gracearoha’s picture

gracearoha commented

I am running php version 5.2.1 and have been running update.php for several months with no problem...???

Ah, stupid me. I just realized that somehow my permissions had been restricted on my update.php file. i opened this up a bit and was able to run the update.

Hope that helps someone else as well :-)

jurgen’s picture

jurgen commented

I'm using different PHP versions across two sites (4.4.3 & 5.2.1), but it seems that other variables should be considered - httpd versions & installed modules, files & directories permissions, to name a few.

BTW I'm operating these sites in the same hosting (almost identical setups, just not so identical PHP / mySQL versions).

Hope this can help, cheers!

cozzi’s picture

cozzi commented

Well,

I don't know how I did it, but I did. I somehow ended up with duplicate copies of most of my directory folder. Such as modules/modules/... files/files/... sites/sites/.....

Here are the steps I used to fix it.

First - back up your site and your database.

1) I deleted all of the duplicate folders (this went beyond modules. I found it in every directory.) (I think I screw up when using the cp command, but I'm not sure how - that kind of still scares me.)
2) Now, I queried the system table in the db and found that modules/modules/ had become the reference path for all modules in this table. So I ran this sql command on the system table of the db: UPDATE system SET filename = replace(filename,"modules/modules/","modules/");
3) I truncated all cache tables - in PHPmysql that would mean to select each of the following tables (one at a time) cache, cache_filter, cache_menu, cache_page, cache_views and then select the Empty tab for each. BE CAREFUL - do no Empty anything other than a cache table.

Test..Test..Test..

Ciao!
Cozzi

hairypalm’s picture

hairypalm commented

I did almost the same thing. Installed a system update to the sites/all/modules directory and got a similar corruption. This advice was perfect. I noticed you only wrote it today, just when I needed it! Saved me hours of work. My site is back up.

Thanks!

cozzi’s picture

cozzi commented

I've been having weirdness with incorrect Breadcrumbs - have you seen the same since this repair?

thanks
Cozzi

I've answered this question below in "Opps, I never mentioned how I solved this!" - Sorry about the confusing reply post, but originally I thought I was posting a reply to this message but it ended up as a new post which I found I could not delete.

ericstewart’s picture

ericstewart commented

This was exactly the problem that I faced on my site (www.breezy.ca) Youre concise and accurate steps allowed me to get rid of the dreaded "blank page" error when running update.php

Thank you!

/Eric

bradsmokess’s picture

bradsmokess commented

each time a description of the change, there is always plenty to talk about around the world. they are not exempt. a statement usually are: "i have to change almost immediately versions, so do not expect me to date continue to attack ..

PsychoX52’s picture

PsychoX52 commented

I am running 3 different drupal-base sites on the same server, and I tried to run update.php at a new installed site, and it worked so it isn't the server's fault.
The problem was a module in sites/all/modules. Which one? In alphabetic order from aggregator to forum. It's one between them.
How did I solve the problem?
First I backed-up my modules. Then I disabled tinimce, because update editor might require it. After that I've removed all the modules from the directory. The update ran excellent. Finally I put the modules back (from the back-up made earlier). Hope it helps.

kkarpou’s picture

kkarpou commented

The problem was a module in sites/all/modules. Which one? In alphabetic order from aggregator to forum. It's one between them.

In my setup, the culprit was the Filter module; deleted the duplicate and the script run like a breeze :-)

kacy’s picture

kacy commented

I renamed sites/all/modules into sites/all/modules.old, ran the update.php and then renamed it back. It worked ! Thx for the tip ;)

cozzi’s picture

cozzi commented

This post answers my question about "Are your BreadCrumbs messed up since?"

I was having an issue with showing incorrect breadcrumb trails.

Many of my breadcrumb trails were incorrectly showing "Image Galleries" as my current destination, when in fact I was viewing a blog, or view etc...

I found the culprit to be one of my Category terms. It was "All Pics", and after I changed it to "All Pictures" the problem evaporated. Again, don't ask me why, I have no idea.

cgdigitaltreats’s picture

cgdigitaltreats commented

ini_set('display_errors', FALSE);

Set it to true.

Thank you for your insight.

cgdigitaltreats’s picture

cgdigitaltreats commented

Hi,

I some how moved a module like forums into another module, and then copied forums back (a new one) because I noticed it was missing. Then when I went to update, blank screen. I figured out what I did, (mouse was to sensitive)
Deleted the duplicate and update worked.

If a module is hiding inside of a folder, essential a duplicate, update might have problems.

Just something that happened to me.

Antonio

cgdigitaltreats’s picture

cgdigitaltreats commented

For all of you that get that blank screen, and don't want to go crazy figuring it out.

I use firefox and the add in module fireftp.

Place your site in maintenance mode.
goto your ftp program, log into where your drupal instal is.
Rename your module folder as oldmodules
download the drupal.zip that you have installed. In my case it was 5.7
Then copy the modules folder to your site.
Check your update module, it should work.
Copy your modules back from the old folder one at a time.
No need to copy over the core modules since you just reinstalled them.

You can see where I'm going with this.
IF a module was causing the problem, you effectively cleaned it up.

It's a bit time consuming if you have a bunch of modules, Sometimes I would copy half of the old ones from the folder,(minus core) and check, (making sure to remember which half I moved back.) Then move half of the remaining. If the problem pops up you know generally where the bad module is.

After your done, you can delete the oldmodule folder.

Antonio

rcharles’s picture

rcharles commented

Nobody told me there'd be days like these...

Decent tip I suppose but man oh man These Druapl issues always seem painful when you are not being paid to do it.

Lythia’s picture

Lythia commented

brilliant! thank you

seanknight11@hotmail.com’s picture

seanknight11@hotmail.com commented

Yeah I had the same problem. I deleted all of the duplicates and moved modules back into the correct root module folder if they weren't already and then I went through the DB and fixed all the module file paths (system table) to point back to the correct location. Now my update won't work...

I've never had a problem with update.php before, however, this installation of Drupal it seems broken. I get a 500.shtml "requested page not found page" when I run it. Which is even stranger than a blank white page. no errors in the log unfortunately. Any ideas?

cgdigitaltreats’s picture

cgdigitaltreats commented

The developer module has a feature called reinstall module.

It might help.

Antonio

tobias’s picture

tobias commented

this error checking display helped me to fix my problem as well. I fixed the module files and corrected the paths in the system mysql table, and all is well.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

I think it's probably a poor decision turning off errors in the update.php. Turning it back on helped me right away to discover my error - when unzipping modules in the modules directory, I had accidentally unzipped a copy of the drupal distribution. With the error display turned on, it was a snatch to debug. Before turning on 

ini_set('display_errors',TRUE);

there was nothing, not in the webserver error log, nothing. But with it turned to true, I was out of trouble in no time.

Thanks!

endlasuresh’s picture

endlasuresh commented

thanks this has been solved i think the main problem is the hosting

rbritan’s picture

rbritan commented

Hi to all

I just figured that a Drupal instalation via "Fantastico" the update.php file does not exist. So I just had to upload the file and run the script

cgdigitaltreats’s picture

cgdigitaltreats commented

I had a wierd problem where a module got copied to the root instead of the modules folder.
Update stopped working. I went into phpmyadmin, and checked on the database.
Sure enough, in the system item, where all the module paths are, the path was wrong.
Updating all the paths, fixed the update. I of course deleted the module and reuploaded it into
the modules folder.

Antonio

tclusellas’s picture

tclusellas commented

Thank you a lot, fix it for me as well.

jquery’s picture

jquery commented

Don't delete one of the default themes. The update.php will use one.

gribu’s picture

gribu commented

That's works for me 2!
THANKS!!!

3lite’s picture

3lite commented

Leave your default themes alone... even if you set your system theme to something else...
Garland is used by update.php and other modules.

This fixed my problem, thanks!

-=---
Washington Pages
KipTip - Coming soon...
-=---

_drake_’s picture

_drake_ commented

That was the problem for me too. Thank you

dafreak’s picture

dafreak commented

Ya, my Garland theme was messed up for some reason and files were missing, so I got white page of nothingness on update.php.
Ahh well, live and learn.

Cheers,

DaFreak!!

Anonymous’s picture

Anonymous (not verified) commented

Yeah thats it

asugene’s picture

asugene commented

It appears many things causes this error. I got a blank page when we used a domain backup for installation of a Drupal install in another domain. I read in the error log that for some reason my old location was listed in the public_html/includes/bootstrap.inc line 984. I changed it to the correct location of the site and it fixed my problem.

edro13’s picture

edro13 commented

I had this problem, and for me, I had deleted the Garland theme from the themes directory.
After I replaced the Garland folder (and its contents), everything worked fine.

ineedhelp’s picture

ineedhelp commented

For me, it was quite different... Drupal was looking for the theme (in my case, it was "sky") in /themes/ instead of /sites/all/themes/

Rather than changing /includes/theme.inc, i decided to just copy back the theme file into /themes/

Still, I think it's bad practice to place custom/downloaded themes into just /themes folder...

If anyone has any idea of an alternative way to keep custom themes in a separate folder and make drupal find it, please let me know!

silvesterd’s picture

silvesterd commented

i had several update problems: blank screens, 500s, mystical module errors... so i just had to set update_free_access in settings.ini to "TRUE", (settings.ini permissions from "444" to "777")
rename my modules folder in sites/all to #modules, and update runs.
now, when i want to go to /user, i got this 500 again. 1and1..

vrsotto’s picture

vrsotto commented

its good to note sometimes that some of modules are needed to be disabled first before going to upgrade...

sarahwbs’s picture

sarahwbs commented

This happened to me, too. Turns out that /includes/lock.inc hadn't gotten copied over (for some reason svn left it out when I did an export). Once I copied that file over, everything was fine.

marrydavidson101’s picture

marrydavidson101 commented

I'm pretty much at a standstill until I can figure this out. I can't find any errors in Drupal or Apache to even try to start debugging this.

Any suggestions or guess more than welcome.

Thanks,

Mitnick’s picture

Mitnick commented

If you're using your own theme, leave one of the core themes in tact and enabled (for me it's Garland) for update.php's use. This fixed my problem just now. Hope this will help.

RobertNelsonVance’s picture

RobertNelsonVance commented

Didn't solve the problem for me.

stryder’s picture

stryder commented

Just to add to the knowledge base here ... by default my LAMP installation has open_basedir defined and active in the php.ini. Normally I would add the path to the top folder of my test site to this line and everything would work but since I have several virtual servers in a folder, I used the full path to my main "websites" folder this time round. I can view the pages but when it came to update.php I get blanks. Admin pages also served blanks. I commented out the open_basedir line in php.ini and all is well now. Took me half a day. Haven't got round to figuring out why. Hope this helps someone.

97transam’s picture

97transam commented

Found this page through a google search. I'm grateful for everyone's postings and tried some of the suggestions but still had the blank page. Did a "view source" to see if there would be a clue on what was failing. Code line stopped after
Call to undefined function phptemplate_get_ie_styles() in ....../themes/garland/maintenance-page.tpl.php
So I just uploaded the whole Garland theme back into the themes folder. Reload the "update" page and it appeared!!!

So I registered...
ron

lanouettea’s picture

lanouettea commented

I have been struggling with this problem for a whole day.

Setting the display_error variable to true changed nothing for me.. Google Chrome was not displaying any errors anyway.

Seems like my problem with the blank update.php page was caused by the minelli folder that had been deleted from the /themes/garland folder. I think that this theme contains default theme informations for when the site is put in maintenance mode.

So if you tried everything above and nithing works.... simply download the core drupal installation and grab the /themes/garland/minelli folder and put it in your website installation's /thems/garland folder.

I hope this helps!

peddyfab’s picture

peddyfab commented

Hello,
NewB...Pls i need a step by step help on how to fix this problem...i can only view this while trying to logon to my site.
Fatal error: Call to undefined function filter_xss_admin() in D:\Hosting\7381778\html\sites\all\modules\views\plugins\views_plugin_display_page.inc on line 182
Helping me out would really be appreciated,thanks

reservetous.com

rfiertek’s picture

rfiertek commented

What worked for me finally -- just temporarily switch your main theme over to Garland. I had earlier in the day switched from Drupal to Pressflow, so I also went back in and threw the original Drupal Garland directory back into the new Pressflow directory -- don't know if it made the difference, as that drop in alone did not cause update.php to do anything but continue to show the blank page, but I do know I was then able to get to the modules update page after I changed the main theme to the Garland theme.

Rob

Grifforg’s picture

Grifforg commented

Just had the problem on a Drupal 7.22 install after updating the Zen theme. Don't know if the problem occurred because of this update, but after a long search to fix the issue, I opened the update.php file to see there were nothing in: no code at all. I copied the content from my Acquia Dev Desktop local original development site update.php file and pasted it in the distant one and that was the solution. I wasted time searching a solution everywhere, I should had have a look at this file first!

SimonSherrington’s picture

SimonSherrington commented

In case it helps others, when faced with blank update.php page (in fact blank site) after core 7.27 upgrade, following advice above, I disabled all non-core modules (by renaming contributed modules directory in sites to modulesold), re-enabled Garland and set as default theme. Reinstalled the Drupal core files. Update.php then worked fine. Reverted to original modules directory name. Had to re-enable the various modules in config page but once done all worked ok.

squirkie’s picture

squirkie commented

I'm getting the same thing...the whole site is blank, including the update.php page. I've tried following the advice above (disabling non-core modules), and re-uploading the Drupal core files, but everything is still blank. Does anyone have any other advice on how to proceed from here?

jaypan’s picture

jaypan
Location Victoria, BC
commented

Look in your php and apache error logs to find out what the error is that is causing the problem.

Contact me to contract me for D7 -> D10/11 migrations.

dhruv panchal’s picture

dhruv panchal commented

If you are getting blank page while running update.php, then please comment below line from update.php file and remove site from maintenance mode:-

define('MAINTENANCE_MODE', 'update');

Thanks

prairiedog’s picture

prairiedog commented

Based on the advice to comment out the line regarding maintenance mode (as above), this led us to find out that - for some crazy reason -- our update.php file was empty. We have no idea why (we had issues after updating Metatag after a security release [Feb 2019], but we don't know if the two are related). We're just mentioning it here in case anyone else ever experience the "blank white page" after trying to run updates.  

After we replaced update.php with the proper file, things worked as they always have. That this happened is worrisome (the scratching question of "why..."), and if anyone has any ideas, we'd appreciate feedback. We'll study everything on the server and the site in the meantime.