2

I'm testing a partial backup of a frankly rather outdated (legacy, what can you do?) CentOS/Apache/MySQL/PHP/Wordpress server by restoring to a VM with a fresh copy of the relevant packages. After many trials and tribulations, I've gotten to the point where I can successfully wget a nice 200 OK response from http://<site-domain-name>/ (which just goes to localhost by virtue of hosts file shenanigans). Unfortunately, the body is zero-length, and the logs are basically empty.

phpinfo() reports that display_errors, display_startup_errors, and log_errors are all on, and error_log is set to /var/log/php_error, which does not exist; error_reporting is a nice tidy 32767. The reported MySQL, PHP, and Apache versions are more or less as expected: 5.0.95, 5.3.29, 2.2.23; Wordpress is 3.9.2.

httpd.conf is ridiculously long and messy, but /etc/httpd/logs/error_log, /etc/httpd/logs/defSite_error_log (virtual-host-specific), and /etc/httpd/logs/defSite_access_log (also virtual-host-specific) all exist and are written to at intervals; nothing of real interest shows up, either time-wise or content-wise as far as I can tell, though the error log is set to debug-level.

All PHP files in the directory (and subdirectories) are owned by the apache user that I've verified the httpd worker processes are running as, and all are -rwxr--r--.

I've verified that the MySQL connection information is right in wp-config.php. mysql, mysqli, and pdo_mysql are all enabled in the phpinfo() output.

xdebug + WinCacheGrind says that PHP is spending 2001ms in wp-blog-header.php and what it calls (1830ms of that in wp-settings.php and friends), which seems a bit excessive for a mostly-static page, albeit one being rendered in a VM on a slow laptop; nothing is calling die().

/wp-admin/options.php 302-redirects over to /wp-admin/upgrade.php, which then says that no upgrade is required (?) and has a Continue link pointing at the site root. /wp-login.php, on the other hand, looks plausible, except that it uses the IP address of the live site. Based on that, I went into the database and switched the numeric IP to the domain name (i.e., siteurl and home in wp_options). Now /wp-admin/upgrade.php says it needs to update the database before continuing.

I've probably left out some stuff by mistake, but let me know what other checks I should run and I'll see what I can do.

7
  • Are you sure you're calling a php script and not rendering a blank index.html file or something? If so you can get that with e.g. die(); in the php code (to state the obvious). If there are no log/error message you need to debug and step through the php code to see what it's doing. Or, e.g., generate an xdebug profile and look at the methods called to determine why it stops with no output.
    – AD7six
    Jan 31, 2015 at 9:28
  • @AD7six: Yes, I'm sure it's PHP, since I reused the same file to generate phpinfo(). It's possible it's calling die(), but why would WP do that on this server when it doesn't on the (functioning) main site? Jan 31, 2015 at 23:43
  • @AD7six: Checked xdebug, but not entirely sure what to look for; seems to be doing a lot of plausible stuff, though. Feb 1, 2015 at 3:14
  • In the scope of system administration it looks like you've reached the end of the road. Assuming there really are no log messages anywhere (are you sure?), appropriate cache/tmp files have been deleted and you've updated the database data if the domain name has changed - you need to debug the php code to determine why it results in a blank page - which is a task for a php developer and off topic for server fault.
    – AD7six
    Feb 1, 2015 at 21:31
  • Does the wordpress system expect the correct domain in the HTTP Host header? Perhaps it's barfing because you're using the fake-loopback-using-hosts trick? Maybe use hosts to redirect the real domain name to localhost temporarily?
    – fukawi2
    Feb 2, 2015 at 4:06

1 Answer 1

3

Just run into almost exact the same problem today. Traced the code and then find the cause. It is because one of the plugins does not throw errors and just EXIT!!

You can tell which plugin it is by var_dump each of the elements of wp_get_active_and_valid_plugins() in wp-setting.php.

The last plugin shown here is the one which caused the problem.

So there were no errors at all.

enter image description here

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .