How Should I Use WP_DEBUG?

WP_DEBUG should be used as a temporary troubleshooting tool, not as a permanent setting.

When something goes wrong on a WordPress site, WP_DEBUG can help expose PHP errors, warnings, and deprecated code messages that WordPress might otherwise hide. Those messages can point you toward the plugin, theme, or function involved in the problem.

The key is using WP_DEBUG carefully. You want WordPress to collect useful debugging information without showing raw technical messages to visitors or leaving unnecessary logs behind after the issue is solved.

Use WP_DEBUG When You Need More Information

You should turn on WP_DEBUG when you have a problem that may involve PHP or WordPress code.

For example, it can help when:

• A page shows a fatal error.
• A plugin or theme stops working.
• A custom code snippet breaks something.
• A feature fails after an update.
• WordPress reports a critical error.
• A process fails without explaining why.

WP_DEBUG is most useful when the issue is reproducible. If you can trigger the problem again after enabling debugging, WordPress has a chance to record the error.

Do Not Use WP_DEBUG as Your First Guess for Every Problem

Not every WordPress issue can be captured via WP_DEBUG.

If a page looks wrong but still loads, the problem may be CSS. If a button does nothing, the issue may be JavaScript. If the site is slow, the cause may be database queries, caching, hosting, or external requests.

WP_DEBUG is mainly useful for PHP-related issues. It can be part of a larger troubleshooting process, but it is not the only debugging tool you need.

Use WP_DEBUG With Logging Enabled

The most common way to use WP_DEBUG is to pair it with WP_DEBUG_LOG.

To do this manually, open your site’s wp-config.php file and add the following above the line that says /* That's all, stop editing! Happy publishing. */:

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

This setup does three things:

WP_DEBUG turns WordPress debugging on.

WP_DEBUG_LOG tells WordPress to save debugging messages to a log file.

WP_DEBUG_DISPLAY prevents those messages from being printed publicly on your site.

This is usually the right approach for a live site because it lets you collect information privately.

Reproduce the Problem After Enabling Debugging

Turning on WP_DEBUG is only part of the process.

After enabling it, you need to repeat the action that caused the issue. Reload the broken page, run the failed import, or perform the same admin action again.

WordPress can only log what happens while debugging is enabled. If the error happened before you turned on logging, it won’t appear in the log file.

Check the Debug Log

When WP_DEBUG_LOG is enabled, WordPress normally writes errors here:

/wp-content/debug.log

Open that file and look for entries from the time you reproduced the issue.

Useful entries may include:

• The error type
• The error message
• A file path
• A line number
• A plugin or theme folder
• A function or method name

If a path points to /wp-content/plugins/, a plugin may be involved. If it points to /wp-content/themes/, the theme may be involved. If it points to WordPress core, do not assume core is the cause. A plugin or theme may have passed bad data into a WordPress function.

Focus on the Relevant Entries

A debug log can contain old warnings, repeated notices, and messages that are unrelated to the current problem.

Do not treat every line as equally important.

Start with entries that appeared immediately after you reproduced the issue. Give special attention to fatal errors, repeated messages, and anything that references the feature, plugin, theme, or page you were testing.

If the log is too noisy, save a backup copy, clear the file, reproduce the issue again, and then review the fresh log.

Turn WP_DEBUG Off When You Are Done

WP_DEBUG is for investigation.

After you have collected the information you need, turn it off again by changing:

define( 'WP_DEBUG', true );

To:

define( 'WP_DEBUG', false );

You can also remove old log files if you no longer need them.

Leaving debug logging enabled indefinitely can create large log files and unnecessary clutter. On a live site, it is better to collect the information you need, solve the issue, and then return the site to its normal state.

Use WP Debug Toolkit for Efficiency and Convenience

You can use WP_DEBUG manually, but editing wp-config.php and reading raw log files is not always convenient or efficient.

As an alternative, you can perform most debugging tasks from within the WordPress dashboard using WP Debug Toolkit:

You can review errors in the Error Log Viewer:

And investigate database activity in the Query Viewer:

WP Debug Toolkit also lets you monitor your website 24/7 and use sophisticated crash recovery tools that work even if you lose access to WordPress admin:

Final Answer

How should you use WP_DEBUG?

Use it temporarily when you need WordPress to reveal PHP-related errors during troubleshooting. Pair it with WP_DEBUG_LOG so errors are saved to a log file, and set WP_DEBUG_DISPLAY to false on live sites so visitors do not see raw error messages.

Then, reproduce the issue, review the newest entries in /wp-content/debug.log, and use the error details to decide where to investigate next.

When you are finished, turn WP_DEBUG off again.

WP Debug Toolkit lets you do all of this from within the WordPress dashboard.

For other options, see the 5 Top WordPress Debug Plugins.