Mysql – 200 OK blank page setting up WordPress on restore test VM

apache-2.2centos5MySQLphp5Wordpress

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.

Best Answer

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