WordPress Debugging: Transitioning from WP_DEBUG_DISPLAY to WP_DEBUG_LOG for Production

Direct Answer

A server-level display_errors = Off in php.ini does not automatically override WP_DEBUG_DISPLAY. WordPress applies its debug constants at runtime through ini_set() inside wp_debug_mode(), so the constant typically wins unless the host has locked the directive with php_admin_flag or php_admin_value.

WP_DEBUG_LOG fails to write in several specific scenarios even when the constant is set to true:

• WP_DEBUG is false or absent—WP_DEBUG_LOG is ignored entirely.
• The web-server user lacks write permission for wp-content/debug.log.
• open_basedir restrictions block the wp-content path.
• log_errors is disabled or locked by the host.
• The filesystem is read-only or the disk is full.

Confirmed Facts vs. Likely Explanation

Confirmed behavior: WP_DEBUG_LOG=true directs PHP errors to wp-content/debug.log relative to the WordPress root. WP_DEBUG_DISPLAY=false suppresses on-screen output while still allowing the log file to capture entries.

Likely explanation: because wp-config.php constants are applied at runtime rather than replacing php.ini, they remain subject to PHP's override hierarchy and filesystem checks. If a managed host enforces error-handling directives at the pool or server level, the constants may be silently ignored.

Steps to Diagnose and Resolve

1. Confirm wp-config.php contains WP_DEBUG true, WP_DEBUG_DISPLAY false, and WP_DEBUG_LOG true.
2. After WordPress loads, check effective values with a temporary phpinfo() or ini_get('display_errors') / ini_get('log_errors') to see whether the runtime values match expectations.
3. Verify the web-server user can write to the log path:

   ls -l wp-content/debug.log

   If the file does not exist, check directory permissions on wp-content/.
4. Trigger a PHP notice (for example, an undefined variable) and confirm that nothing appears in the browser while an entry is appended to wp-content/debug.log.
5. If the log remains empty, inspect open_basedir, log_errors, and available disk space.

Because debug.log can expose absolute paths and plugin internals, block direct HTTP access to it via server rules. On high-traffic production sites, monitor disk usage—continuous error logging can fill storage and degrade performance.

Missing Diagnostic Detail

Are display_errors or log_errors locked by your host via php_admin_flag or php_admin_value? If they are locked, wp-config.php constants cannot override them and you must ask the host to adjust the pool configuration. If they are not locked, the issue is almost certainly filesystem permissions or an open_basedir restriction.