WordPress Debug Mode and Error Logs

WordPress debug mode exposes notices, warnings and errors that can reveal the cause of a failure.

Debugging should be enabled deliberately, recorded and disabled or secured after the investigation.

Core Debug Constants

Common constants include:

• WP_DEBUG to enable WordPress debug behavior.
• WP_DEBUG_LOG to write errors to a log.
• WP_DEBUG_DISPLAY to control browser display.
• SCRIPT_DEBUG to load development versions of core CSS and JavaScript.
• SAVEQUERIES to collect query information for development diagnostics.

These values belong in wp-config.php before WordPress finishes loading.

Production Safety

Public error display can expose:

• File paths.
• Plugin names.
• SQL details.
• usernames.
• server configuration.
• personal data.

Prefer protected logging rather than browser output on production.

The default wp-content/debug.log location may be web-accessible on some servers. Move or protect it where necessary.

Reproduce the Exact Problem

Record:

• URL and action.
• timestamp.
• user role.
• browser.
• recent changes.
• request identifiers.
• relevant log lines.
• whether the problem occurs on staging.

Logs without timing and reproduction steps are difficult to interpret.

PHP and Server Logs

WordPress logs are only one source.

Also review PHP-FPM, web-server, database, proxy, CDN and hosting logs when the failure occurs before or outside WordPress.

Query Logging

SAVEQUERIES can add overhead and memory use.

Use it for short controlled investigations rather than leaving it enabled permanently.

Frequently Asked Questions

Should WP_DEBUG remain enabled on production?

Public display should not remain enabled. Protected logging can be used temporarily when required.

Why is debug.log empty?

The error may occur before WordPress logging starts, the file may not be writable, or PHP may log elsewhere.

Continue Learning

Previous: Monitoring Uptime, Errors and Website Health

Next: WordPress Recovery Mode