Everything you need to know about the wp-config Debug Helper
Overview
The wp-config Debug Helper generates the precise wp-config.php constants needed to capture WordPress fatal errors, notices, and deprecations to a private log file you can read, without exposing errors to live visitors. It produces the safe combination of WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, and SCRIPT_DEBUG that experienced WordPress developers use during incident response.
The tool also explains how to set custom log paths, how to rotate large debug logs, and how to disable error display on production while still recording everything to disk. This is essential for debugging issues that only appear under real traffic.
Why this matters for WordPress site owners
WordPress error logging is off by default, which means fatal errors disappear into a blank page or a generic '500' message. Without a properly configured wp-config.php, you cannot identify which file or plugin triggered the error, and you end up guessing. A correctly enabled debug log shortens diagnosis from hours to seconds.
How to use this tool, step by step
- 1Select your goal: log only, show only, or both.
- 2Indicate whether the site is live or staging so the tool can recommend safe defaults.
- 3Copy the snippet, paste it above the 'That is all, stop editing!' comment in wp-config.php, and save via FTP.
Expertise and methodology
The snippets follow the current WordPress core defaults for the 6.x release line and reflect the recommended production-safe pattern: log to disk silently, never display errors to visitors. The tool also reminds you to disable debugging after recovery, which is a frequent oversight on production sites.
Common mistakes to avoid
- Leaving WP_DEBUG_DISPLAY enabled on a live production site, which can leak file paths.
- Storing debug.log in a publicly accessible folder. Always keep it inside /wp-content with default permissions.
- Forgetting to remove the snippet after the incident is resolved.
