[SOLVED] Blank Page (not Suhosin!)
I am managing five separate Wordpress instances, and two of them are giving me the dreaded Blank Page when I try to upgrade. Here are the facts:
#'s 1, 2, 3, and 5 are housed on one host. #4 (ABCD Australia) is housed on a different host (the "business hosting" level). One would expect that the troublesome sites would be the ones on the same server, but they are not! It is #1 and #2 that are giving us trouble. The other three are not. I can see no consistent element in these two that is missing from the other three; nor can I see anything missing from these two that is present in the other three. I would love a clue. I read the Suhosin thread with interest and systematically tried all the shenanigans suggested there with the php.ini and .htaccess, but no joy. Then it occurred to me to look at fwb.ca, and to my great surprise I discovered that it is already at 3.4.6 and working fine! Since it is on the same host (and directory!) of mindcamp.org, I infer that the issue isn't Suhosin. I have tried deactivating and removing all plugins, but no joy. Does anyone have any suggestions? |
just because you have multiple sites on the same host, doesn't mean that they are on the same server and if they are on different servers the code levels of php may be different.
At my host, I did not have the suhosin issue, but I was setting up a customer of mine at the same host and they do have the suhosin issue. They are on a different server (newer and it has suhosin installed. The easiest thing I know to do to check is to add HTML Code:
<?php if (current_user_can( 'list_users' ) ) { phpinfo(); } ?> Then you can search the output for the word 'suhosin' |
Thanks for getting back to me so fast! Now I have new information (including more about suhosin) as follows:
The hosting provider wrote back saying "yes we use Suhosin" (I should rename this thread!) so I returned to the Suhosin thread with new determination. For some fortuitous reason I tried the fixes on Site #1, Art Building Children's Dreams, instead of Mindcamp... I hadn't done that before because I assumed the hosting was identical. Adding "suhosin.executor.include.whitelist = bfa://" to php.ini worked! I was able to upgrade to 3.6.4. :) Naturally I immediately went to mindcamp.org and tried the same code modification but no joy. :( Differences between the sites: 1. abcdreams.ca was at Atahualpa 3.5.3, mindcamp.org was (and is) at 3.4.6 2. for some reason mindcamp.org was set to php4. I found an "AddHandler php4-script .php" command in the .htaccess file (when did I put that there and why? I should have commented) -- took it out and reset mindcamp.org to php5 (and debugged THAT, long story) but still no joy. I have been in touch with the host... after the initial "we don't troubleshoot third party scripts" bullshit they've become helpful and interested...so I've described my experiments and asked if they have any thoughts as to precisely why the two sites are behaving differently. I will keep you posted on that. However in the meantime I have tried your suggestion. Yes suhosin naturally did appear; in case the details are relevant I include them below. There was also another interesting difference in the line for Registered PHP Streams, as shown below: https, ftps, compress.zlib, compress.bzip2, php, file, data, http, ftp, bfa (abcdreams) https, ftps, compress.zlib, compress.bzip2, php, file, data, http, ftp (mindcamp) AHA!!! "bfa" appears in abcdreams (working) but not in mindcamp (not working). But here's the crazy thing: the line "suhosin.executor.include.whitelist = bfa://" IS in the php.ini file of both. Any thoughts? Thanks so much! ----- relevant output of the Center Column loop is identical in the two: suhosin.log.phpscript 0 0 suhosin.log.phpscript.is_safe Off Off suhosin.log.phpscript.name no value no value suhosin.log.sapi no value no value suhosin.log.script no value no value suhosin.log.script.name no value no value suhosin.log.syslog no value no value suhosin.log.syslog.facility no value no value suhosin.log.syslog.priority no value no value suhosin.log.use-x-forwarded-for Off Off |
I would suspect that they don't allow the php.ini (are ignoring it) in the one that doesn't work or it has to be in a different location.
|
This is now resolved: I created a completely clean install of Wordpress using Atahualpa 3.6.4 in another folder on the same server, and then used phpMyAdmin to import the old database onto the clean install table by table.
The problem table was wp_options, not surprisingly. Some pretty random stuff seems to get thrown into that table: when I rebuilt the installation by going through and re-creating all the WP, Atahualpa, and plugin options) the new table was only 190 variables whereas the old was 350+. Anyway once I was satisfied the sites were identical I just imported the clean table back into the old DB, corrected the "siteurl" and "home" variables to match the old URLs (they were of course reflecting the new URLs) and now it works fine. I have no idea what the offending variable was but it's gone, and that's good! The important thing is that all my pages, posts and comments were preserved; it took a while to rebuild all the options (just my luck that the import/export option wasn't yet available in the version of Atahualpa I was using) but I learned a lot about working directly with the DB; a useful education. Thanks for your help. Franca |
All times are GMT -6. The time now is 10:54 PM. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.