How to Enable WordPress Debug Mode Safely

Quick setup: back up wp-config.php, add the constants below before the “stop editing” comment, reproduce the error once, then inspect wp-content/debug.log. Keep display disabled so visitors never see stack traces.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress recommends debugging on staging. On production, use this configuration only for a short controlled diagnostic window.

What each setting does

WP_DEBUG

Enables WordPress debug behavior and PHP notices/warnings reporting. Use the boolean true, not the string 'true' or 'false'.

define( 'WP_DEBUG', true );

WP_DEBUG_LOG

Writes errors to the default log when set to true:

wp-content/debug.log

It can also accept an absolute file path:

define( 'WP_DEBUG_LOG', '/secure/path/wordpress-errors.log' );

A path outside the public web root is preferable when the host permits it.

WP_DEBUG_DISPLAY

Controls whether errors appear inside generated pages. Keep it false on every public site:

define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

The official Debugging in WordPress handbook documents these constants and notes that WP_DEBUG_LOG and WP_DEBUG_DISPLAY depend on WP_DEBUG.

Edit wp-config.php in the correct place

Place the definitions above:

/* That's all, stop editing! Happy publishing. */

and before:

require_once ABSPATH . 'wp-settings.php';

Search the file first; duplicate definitions cause warnings and make it unclear which value is active.

Do not edit wp-config-sample.php. WordPress reads wp-config.php.

Reproduce one request at a known time

Clear or archive an old log, note the current time and reproduce the exact problem once. Examples:

• submit the failing form;
• open the blank page;
• run the failed plugin update;
• make the API request;
• process one test order.

Then read from the bottom of the log. This reduces noise from unrelated bots, cron and older warnings.

Read the useful part of an error

Prioritize:

PHP Fatal error
Uncaught Error
Allowed memory size exhausted
Parse error
Call to undefined function

Record:

• timestamp;
• error type and message;
• first project/plugin/theme file path;
• line number;
• preceding action;
• component and PHP versions.

A stack trace can mention WordPress core even when the first caller in a plugin caused the problem. Do not edit a core file solely because it appears last.

Warnings and deprecation notices matter for maintenance but may not explain an outage. Match the timestamp and symptom.

If debug.log is missing or empty

Check:

1. WP_DEBUG is boolean true;
2. definitions are before wp-settings.php;
3. the error was reproduced after enabling logging;
4. wp-content or the configured log path is writable by PHP;
5. the host did not override PHP logging;
6. the failure occurs after WordPress starts loading.

For syntax errors in wp-config.php, web-server failures or PHP-FPM startup problems, use the host’s PHP/server error log. WordPress cannot log an error that prevents WordPress itself from loading.

Optional debugging constants

Use these only for the relevant problem:

define( 'SCRIPT_DEBUG', true );

loads development versions of WordPress core CSS/JavaScript and is useful when debugging core scripts—not as a general performance fix.

define( 'SAVEQUERIES', true );

records database queries and timing in memory. It adds overhead and can expose query context, so use it briefly on staging and remove it immediately.

Disable debugging after diagnosis

Restore production-safe values:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Delete or archive the log securely, confirm it is not publicly downloadable, and remove temporary permissions. Logs can grow quickly and consume disk space.

If the log identifies a plugin but wp-admin is unavailable, use How to Disable WordPress Plugins Without Admin Access. If it reports memory exhaustion, use the memory-limit guide.