Diagnostic tool

wp-config Debug Helper

Name: wp-config Debug Helper
Author: GrowrAI Editorial Team

By GrowrAI Editorial Team• 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

What this tool does

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.

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.

Runs in your browser

No files uploaded, no credentials requested.

Maintained by people

Reviewed and kept current by the GrowrAI editorial team.

Tested on live sites

Every fix path verified on a real broken WordPress install.

Scroll down for the full walkthrough, common mistakes, and FAQs. If you already know what you need, use the form below to get an instant recommendation.

Step 1: Describe the issue

What do you want to do?

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 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

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.

Reviewed and maintained by GrowrAI Editorial Team. Every fix path is tested on a live WordPress install before it is published here.

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.

Why wp-config.php deserves more care than any other file

wp-config.php holds the database credentials, the security salts and every constant that changes how WordPress behaves. It is loaded before anything else, which has two consequences: a single misplaced character takes the entire site down instantly, and any debugging constant you set here applies everywhere, including pages visitors can see. That is why the correct debugging setup writes to a file rather than to the screen.

The most frequent way people break this file is a stray space or a blank line after the closing PHP tag, which sends output to the browser before WordPress can set its headers and produces the 'headers already sent' warning. Removing the closing tag entirely at the end of the file is a safe habit and eliminates that whole class of problem. Editing through the WordPress dashboard file editor while a site is unstable is the other common mistake; if the edit is wrong you lose the dashboard and with it your ability to undo the edit.

A debugging setup that is safe on a live site

The useful combination is WP_DEBUG set to true so errors are generated, WP_DEBUG_LOG set to true so they are written to wp-content/debug.log, and WP_DEBUG_DISPLAY set to false so nothing appears on screen. Adding an ini_set line that turns display_errors off alongside these covers hosts that override the WordPress setting. With that in place you can reproduce the fault on a live site, read the log, and no visitor sees anything unusual.

SCRIPT_DEBUG is worth knowing about separately. Setting it to true makes WordPress load the unminified versions of its own CSS and JavaScript, which turns an unreadable console error into a line number you can actually act on. It makes pages heavier, so it belongs in a short debugging session and not in permanent configuration. When you are finished, remove the debug constants rather than setting them back to false, and delete debug.log, since it can contain full server paths.

Constants that solve real problems, and the ones to leave alone

A handful of defines genuinely earn their place. WP_MEMORY_LIMIT raises the memory available to WordPress when a plugin needs more headroom. WP_HOME and WP_SITEURL hardcode the site address, which is the standard way to break out of a redirect loop caused by wrong URLs in the database, though they override the settings screen and should be removed once the database is corrected. DISALLOW_FILE_EDIT switches off the dashboard file editor and is worth keeping permanently on any site with more than one administrator.

Be cautious with the rest. Disabling automatic updates leaves security patches unapplied. Raising the post revision limit indefinitely bloats the database on content-heavy sites. Turning off the cron system without setting up a real server cron stops scheduled posts, backups and renewals silently, and that failure is invisible until something important does not happen. As with any change here, keep a copy of the working file locally before you edit, and change one constant at a time.