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.

Nathan Tuggy
  • 124
  • 1
  • 1
  • 10
  • 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](http://www.xdebug.org/docs/profiler) and [look at the methods called](https://code.google.com/p/webgrind/) to determine why it stops with no output. – AD7six Jan 31 '15 at 09: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? – Nathan Tuggy Jan 31 '15 at 23:43
  • @AD7six: Checked xdebug, but not entirely sure what to look for; seems to be doing a lot of plausible stuff, though. – Nathan Tuggy Feb 01 '15 at 03: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 01 '15 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 02 '15 at 04:06
  • @fukawi2: I think that's what I'm doing. Edited to clarify. – Nathan Tuggy Feb 02 '15 at 06:07
  • I'll update again once I've gotten wget or something else to handle the database update. – Nathan Tuggy Feb 05 '15 at 03:21

1 Answers1

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

Jasper
  • 63
  • 1
  • 8