You set WP_DEBUG and WP_DEBUG_LOG to true, reload the broken page, and wp-content/debug.log never shows up. Or it exists but stays empty while the site clearly throws errors.
This came up again this week on the WordPress.org forums after WordPress 7.1. Another user tested a fresh 7.1.4 install and logging worked fine, which matches what I see: core logging is not broken. Something on the site or server is overriding it.
Below are the causes I check, in the order I check them.
Put the constants above the “stop editing” line
Back up wp-config.php before you touch it. Then make sure your debug block sits above /* That's all, stop editing! */ and, more importantly, above the require_once ABSPATH . 'wp-settings.php'; line.
WordPress reads the debug constants while wp-settings.php loads. Anything defined after that line comes too late, and the official debugging docs say the same: insert it before the stop editing comment.
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Log errors to wp-content/debug.log
define( 'WP_DEBUG_LOG', true );
// Do not print errors on the page
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Use true without quotes. The docs warn that the string 'false' counts as true, and WP_DEBUG_LOG also accepts a file path, so a quoted value can send your log somewhere you are not looking.
Look for a second define() of the same constant
A PHP constant can only be defined once. If your host or an old migration already put define( 'WP_DEBUG', false ); higher up in the file, that one wins and yours is ignored.
grep -n "WP_DEBUG" wp-config.phpEach constant should show up once. If you see WP_DEBUG defined twice, delete the extra line. With WP-CLI, wp config get WP_DEBUG and wp config get WP_DEBUG_LOG show the values the file defines.
While you are at it, confirm you are editing the right file. If there is no wp-config.php in the WordPress root, WordPress loads the one a directory above it, so on some setups the copy you are editing is not the one being used.
Ask PHP where it is actually logging
Guessing wastes time. This temporary must-use plugin writes a test line and shows you the real log_errors and error_log values after all plugins have loaded.
Create wp-content/mu-plugins/debug-log-check.php:
<?php
/**
* Plugin Name: debug.log check (delete after use)
*/
add_action( 'init', function () {
if ( ! isset( $_GET['debuglog_test'] ) || ! current_user_can( 'manage_options' ) ) {
return;
}
error_log( 'debug.log test ' . gmdate( 'c' ) );
wp_die(
'WP_DEBUG: ' . var_export( WP_DEBUG, true ) . '<br>' .
'log_errors: ' . esc_html( ini_get( 'log_errors' ) ) . '<br>' .
'error_log: ' . esc_html( ini_get( 'error_log' ) )
);
} );Log in as an admin and open https://example.com/wp-admin/?debuglog_test=1. With a working setup you get WP_DEBUG: true, log_errors: 1 and an error_log path ending in wp-content/debug.log, and the test line appears in that file.
The output tells you where to look next:
WP_DEBUG: falsemeans the constants still are not being read. Go back to the first two sections.- The path is right but no file appears: a permissions problem.
- The path points somewhere else, or
log_errorsis empty: a plugin or the server changed it.
Delete the mu-plugin when you are done.
Fix permissions on wp-content and debug.log
PHP writes the log as the user PHP runs as, not as your SSH user. If that user cannot create files in wp-content, or a debug.log already exists and belongs to root, nothing gets written.
ls -la wp-content/ | grep debug
ps -o user= -C php-fpm | sort -uThe first line shows the owner of debug.log if it exists. The second lists the users PHP-FPM runs as (the process may be called php-fpm8.3 or similar on your server, so adjust the name). If the owners do not match, fix it, replacing www-data with your PHP user:
touch wp-content/debug.log
chown www-data:www-data wp-content/debug.log
chmod 664 wp-content/debug.logFind what overrides error_log after WordPress sets it
WordPress points PHP’s error_log at debug.log with ini_set() early in the load. Anything that runs later can undo it: a plugin calling ini_set( 'error_log', ... ) or error_reporting( 0 ), a host mu-plugin, or a security plugin that “hardens” PHP settings.
grep -rnE "ini_set.{0,5}(error_log|log_errors)|error_reporting.{0,3}0" wp-content/plugins wp-content/mu-plugins wp-content/themesAny match in a plugin you run is a suspect. Deactivate it and run the check again.
On the server side, if ini_set is listed in disable_functions, WordPress cannot change the log path at all. And if you used a custom path such as /tmp/wp-errors.log, an open_basedir restriction can block it. Check both with php -i | grep -E "disable_functions|open_basedir", keeping in mind the CLI can use a different php.ini than PHP-FPM.
When the error never reaches debug.log
Some errors happen before WordPress has a chance to redirect logging. A syntax error in wp-config.php itself, or a fatal in an early drop-in, goes to the server’s PHP error log instead. If the site is down with a 500 and debug.log is empty, read the PHP-FPM or web server error log first.
Also remember that a log only fills when something is logged. A page that looks wrong but throws no notice will leave the file empty, which is why the test line above matters.
If you edited wp-config.php and nothing changes at all, OPcache may still be serving the old file on servers that set opcache.validate_timestamps=0. Reload PHP-FPM, or ask your host to.
💡 In OpenPanel you can check log_errors, error_reporting and open_basedir under PHP > Options, and the Statistics > Error Logs page shows PHP and web server errors per website in one place. In cPanel those live in the MultiPHP INI Editor and the Errors page. OpenPanel’s PHP options apply to every domain on that PHP version, so change them with that in mind.
Move the log out of the web root
Once logging works, do not leave it public. wp-content/debug.log can be downloaded by anyone who guesses the URL, and it often contains file paths and query details. WP_DEBUG_LOG accepts a path, so point it outside public_html:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/username/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
The folder must exist and be writable by the PHP user, and it has to be allowed by open_basedir if your host sets one. When you are done debugging, set WP_DEBUG back to false so the file does not grow forever.
For the basics of each constant, see how to enable WP_DEBUG in WordPress, and for a wider debugging workflow, how to properly debug in WordPress.
TL;DR: If debug.log stays empty, the constants are usually defined too late or twice, PHP cannot write to wp-content, or a plugin resets error_log. Run the small mu-plugin check to see where PHP really logs, fix that one thing, and move the log outside the web root once it works.
