• It may save some time to state up front that I have already disabled _all_ plugins and changed the theme to 2019.

    === Original post follows ===

    This might be a tough one, or it might be something simple I have overlooked.

    I maintain a WordPress based website for a customer. System administration, not content production. The website is hosted on a VPS system where I have root access via sudo. Recently I took steps to upgrade PHP from 5.6 to 7.x.

    I take a somewhat conservative approach to system changes, testing WordPress and plugin changes or updates in an Apache Friends XAMPP environment with PHP 5.6 installed on a Windows 7 system. I have a Selenium-based automated test suite that visits all of the front-end pages, and exercises the contact form. This test suite must pass before I update the live site.

    I installed Apache Friends XAMPP (32-bit) PHP 7.2 environment on the same Windows 7 system. I enabled WP_DEBUG and WP_DEBUG_LOG, ran the usual tests, and then extracted the unique errors from wp_content/debug.log. These messages were mostly related to a deprecated way of defining and using class constructors, with a few uses of (deprecated) create_function().

    I modified the offending source files in the theme and one plugin. I also took this opportunity to replace Fast Secure Contact Form with a different forms plugin.

    Another test run and the debug log is clear, and the tests pass. Next step was to take the PHP 7.2 compatible code and database and move it to my PHP 5.6 compatible test environment, and test again. If that passes, then I can take the live site upgrade in two separate steps; first the WordPress changes, then the site PHP changes. Ran the tests; all clear.

    Move the files and database to the live site. Connect to the front end, blank white page (WSOD). I can log in to the back end. I enabled WP_DEBUG and WP_DEBUG_LOG, and restarted apache. WSOD. Disabled _all_ plugins, switched theme to 2019. Restart apache. WSOD, and there is still no wp_content/debug.log file!

    Now what? To be clear, I am not asking to be told what the bug is that I need to fix. But I would love to receive useful pointers on how/where to look for more clues. Thanks.

    • This topic was modified 5 years, 9 months ago by kjohnson_2.
Viewing 6 replies - 1 through 6 (of 6 total)
  • Moderator James Huff

    (@macmanx)

    A blank page means that PHP is crashing, usually due to a function conflict introduced by a plugin or theme.

    Try manually resetting your plugins (no Dashboard access required). If that resolves the issue, reactivate each one individually until you find the cause.

    If that does not resolve the issue, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel (consult your hosting provider’s documentation for specifics on these), navigate to /wp-content/themes/ and rename the directory of your currently active theme. This will force the default theme to activate and hopefully rule-out a theme-specific issue (theme functions can interfere like plugins).

    Thread Starter kjohnson_2

    (@kjohnson_2)

    James,

    Thanks for your interest. I have modified the original post to make it clear immediately that I have already taken the steps you suggest.

    Ken

    Moderator James Huff

    (@macmanx)

    Ok, view the blank page again (this should add a new entry to your server error log), note the date and time, then check your server error log for any new entries within a few minutes of that time.

    Please note that this is the _server_ error log, which is different from WordPress’s debug log. The location of the server error log and how you access it varies greatly depending on hosting provider and server configuration. (in short, we can’t really tell you how to access it)

    Thread Starter kjohnson_2

    (@kjohnson_2)

    (Edited to specify system type.)

    Sure, checking the apache error log makes good sense. This is pretty stock Debian 9.7, so the apache log files are in /var/log/apache2.

    There is not an error message generated in the apache error.log from trying to view the home (blank) page. The access log shows that the favicon is successfully fetched (200), and the home page returns (304).

    A good suggestion. Anyone have more?

    For the benefit of anyone else in a similar situation, because I found this when I was looking at the error log:

    The apache error.log file on the live site does show a message if the Health Check plugin is activated and used — Health Check apparently tries to check if ghostscript is available, so you get an error like:
    sh: 1: gs: not found
    (or, in the test environment, ‘gs’ is not recognized as an internal or external command, operable program or batch file.)

    • This reply was modified 5 years, 9 months ago by kjohnson_2.
    Thread Starter kjohnson_2

    (@kjohnson_2)

    To make my test environment closer to the live site, I updated the test environment to the same version of PHP as the live environment: 5.6.33. This change did not make the test environment fail with the blank page.

    Thread Starter kjohnson_2

    (@kjohnson_2)

    This page:

    Debugging in WordPress

    references a no-white-screen plugin. I tried it, but no new information showed in the logs. I also tried adding a series of sixteen error_log() calls to wp-settings.php. The output from the first call showed up in php.log; the output from the rest of the calls, including the last at the very end of the file was in debug.log.

    • This reply was modified 5 years, 9 months ago by kjohnson_2.
Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Blank page on front end, wp_content/debug.log is empty’ is closed to new replies.