Diagnostic tool

wp-config Debug Helper

By Arjun Mehta Browser only, no data sent

Tell us what you want to debug and we'll produce a safe wp-config snippet.

Get the exact wp-config.php debug snippet your hosting environment needs, with zero guesswork.

No login required Free forever

Step 1: Describe the issue

Frequently asked questions

Is WP_DEBUG safe to leave on?

It is safe but can expose paths. Turn it off after troubleshooting by setting WP_DEBUG to false.

Where is the debug log saved?

When WP_DEBUG_LOG is enabled, errors are written to /wp-content/debug.log.

What is the difference between WP_DEBUG_LOG and WP_DEBUG_DISPLAY?

WP_DEBUG_LOG writes errors to a file. WP_DEBUG_DISPLAY prints them to the browser. On production, log to file and never display to visitors.

Why is my debug.log file empty?

Either no errors have been triggered since enabling it, or the /wp-content folder is not writable. Check folder permissions, usually 755, and file permissions, usually 644.

Can I store the debug log outside /wp-content?

Yes. Set WP_DEBUG_LOG to an absolute path. Keep it outside the web root for security so it is not publicly downloadable.

Will enabling debug mode slow my site down?

The overhead is small for a quiet site, but a noisy site that triggers many warnings can fill the log quickly. Disable debug mode once the issue is resolved.

What is SCRIPT_DEBUG and when should I enable it?

It forces WordPress to load unminified core JavaScript and CSS, which helps when debugging admin or block editor issues. Disable it on production.

Where exactly in wp-config.php should the debug constants go?

Add them just above the line that reads /* That's all, stop editing! Happy publishing. */ so they load before WordPress bootstraps.

In-depth guide

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

  1. 1Select your goal: log only, show only, or both.
  2. 2Indicate whether the site is live or staging so the tool can recommend safe defaults.
  3. 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.

Reviewed and maintained by Arjun Mehta, WordPress recovery engineer, 12+ years rescuing broken sites at WPRescue.

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.

Need hands-on help?

If this tool does not cover your exact situation, contact WPRescue or read the troubleshooting guides. We typically reply within one business day.