We have a bunch of sites using a custom theme we had assistance creating many years ago. When we upgrade PHP on the server from v7.4.x to v8.2.x, we get a critical error message on most of the pages (the header loads, but none of the rest of the page). We do know it has something to do with the theme files, but would like more detailed insight.
When we enable WP_DEBUG, and many of the accompanying options, we just don't get any error messaging or anything written to a debug.log. The only error message we're able to get, or that will trigger the debug.log, is when we enable an older plugin, which gives a deprecated notice.
The following is what we currently have in wp-config.php, but we've tried a number of recommended options, including hiding the fatal error message.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );
define( 'SCRIPT_DEBUG', true );
We've also tried disabling all plugins, which made no difference.
And we edited the php.ini file for PHP 8.2 on the server to change to display_errors = On (is off by default).
We have a bunch of sites using a custom theme we had assistance creating many years ago. When we upgrade PHP on the server from v7.4.x to v8.2.x, we get a critical error message on most of the pages (the header loads, but none of the rest of the page). We do know it has something to do with the theme files, but would like more detailed insight.
When we enable WP_DEBUG, and many of the accompanying options, we just don't get any error messaging or anything written to a debug.log. The only error message we're able to get, or that will trigger the debug.log, is when we enable an older plugin, which gives a deprecated notice.
The following is what we currently have in wp-config.php, but we've tried a number of recommended options, including hiding the fatal error message.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );
define( 'SCRIPT_DEBUG', true );
We've also tried disabling all plugins, which made no difference.
And we edited the php.ini file for PHP 8.2 on the server to change to display_errors = On (is off by default).
Ugh, turns our our themes functions.php file had the following directive, overriding all other error reporting.
error_reporting(E_ERROR);
Moral: Always good to check root theme files if all else fails.
Approach 1: The nuclear options for wp-config.php that I use in a target WordPress installation; as you have said, use it rarely because it does show up on the public facing pages. However, if they are already mis-behaving then go for it. The goal is to enable, show and log as much as possible, disable and then review the displayed page conent and log file content.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
@ini_set('log_errors', 1);
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors', 1);
define( 'SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);
On one of my websites, the debug noise shows up as concern for 2 depreciated functions.
Approach 2: Are there any drop-in and must-use plugins you could possibly remove temporarily, to rule them out of the investigation? I've had to occassionally remove and reinstall the caching plugins after a PHP or WordPress core update.
Approach 3: Add a temporary phpinfo.php file into the website root (aka public_html) directory.
phpinfo.php file and put this one line in it. <?php phpinfo();
phpinfo.php file to the website root (aka public_html) directory.{yourdomain.tld}/phpinfo.php and review the content.error_log directive. It will tell you exactly where the PHP error.log file is located on that specific server. Note that this is the PHP log, not the WordPress wp-content/debug.log file.error_log directive is blank (not pointing to a file) then is it time to get in touch with your server hosting provider and engage them to help you enable PHP logging, temporarily.Approach 4: Setup a local WordPress development environment on your personal computer; using application from www.localwp.com. Create a new blank local WordPress website and add the theme to it. This will allow you to choose a target PHP version to run (like 8.2.x) and open up step-debuging opportunities using Xdebug and your favourite coding IDE (a topic beyond the scope of this answer) with community forum support available.
The above 4 approaches should give you access to all the specific error/warning activity related to the theme.