Direct Answer
WP_DEBUG_LOG does not create wp-content/debug.log. It only tells WordPress to pass that path to PHP's error_log() function. The file is created lazily by the PHP runtime only when an error or notice occurs and only if the wp-content directory is writable by the web-server user (e.g., www-data, nginx, php-fpm). On production hosts where wp-content is owned by a deploy user with 0755 permissions, the PHP process cannot write there, error_log() fails silently, and no log file appears.
Confirmed Facts
- WordPress core (
wp-includes/load.php) checks WP_DEBUG_LOG but never calls mkdir(), touch(), or is_writable() on the log path. This behavior is identical in WordPress 6.x and 7.x.
- If
WP_DEBUG_LOG is set to a custom absolute path (e.g., /var/log/wp-debug.log), the same writability rule applies to that directory.
- A missing
debug.log with WP_DEBUG_LOG enabled is almost always a filesystem-permission issue, not a configuration syntax error.
Likely Explanation for Your Case
Your production host likely runs PHP-FPM under a different user than the one that owns wp-content. The directory permissions (0755) allow the owner to write but not the PHP-FPM user. When WordPress triggers a notice or error, PHP's error_log() attempts to open wp-content/debug.log for appending, receives EACCES (Permission denied), and discards the message without raising a PHP warning.
Steps to Fix
- Verify writability as the PHP user:
sudo -u www-data php -r \"var_dump(is_writable('/full/path/to/wp-content'));\"
Replace www-data with your PHP-FPM user (check ps aux | grep php-fpm).
- If false, create the file and assign ownership:
sudo touch /full/path/to/wp-content/debug.log
sudo chown www-data:www-data /full/path/to/wp-content/debug.log
sudo chmod 640 /full/path/to/wp-content/debug.log
- Or use a dedicated log directory outside the web root (recommended for security):
sudo mkdir -p /var/log/wordpress
sudo chown www-data:www-data /var/log/wordpress
sudo chmod 750 /var/log/wordpress
Then in wp-config.php:
define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log');
- Trigger a test entry:
<?php error_log('WP_DEBUG_LOG test ' . date('c')); ?>
Place in a mu-plugin or theme functions.php, load any page, then check the log file.
Security Note
A web-accessible debug.log can expose stack traces, plugin paths, and database credentials. Always either:
- Place the log outside the document root, or
- Block access via
.htaccess (Deny from all) or Nginx (location ~ /debug\\.log { deny all; }).
One Diagnostic Detail Needed
What user runs your PHP-FPM pool? (Run ps aux | grep php-fpm | head -1 | awk '{print $1}'.) The fix changes if the PHP user differs from www-data or if your host uses a containerized setup where the filesystem is read-only.