Enable WP_DEBUG in WordPress
To enable WP_DEBUG in WordPress, open wp-config.php and set WP_DEBUG and WP_DEBUG_LOG to true above the stop-editing line. Set WP_DEBUG_DISPLAY to false so visitors never see the message. WordPress then writes PHP errors to wp-content/debug.log. Turn the constants off and delete that file after the fix.
A copy-paste WP_DEBUG walkthrough for WordPress users chasing a white screen or a silent plugin fault.
knowledge
- Read time
- 5 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What does WP_DEBUG reveal — and what stays hidden?
WP_DEBUG is the WordPress constant that switches on PHP errors, warnings, notices and deprecated-function messages; it reveals nothing about MySQL passwords and raises no memory limit. Whatever you suppress with WP_DEBUG_DISPLAY stays hidden from visitors while you read it in the log.
A notice means PHP continued past the problem; a fatal means that request stopped dead. On a live site the rule is: log the messages, never print them. The four constants around it each do one job:
| Constant | Value for a live test | What changes |
|---|---|---|
| WP_DEBUG | true, then false again | Turns WordPress debug mode on. false is the normal setting. |
| WP_DEBUG_LOG | true, or a path outside the web root | Writes wp-content/debug.log. Does nothing while WP_DEBUG is false. |
| WP_DEBUG_DISPLAY | false | Stops errors printing into the HTML. |
| SCRIPT_DEBUG | false, unless reading core JS or CSS | Loads unminified core scripts. |
| SAVEQUERIES | false | When true, stores each SQL query on $wpdb->queries and slows the request. |
- true and false are booleans. Quoting them — 'false' inside quotes — creates a non-empty string, which PHP treats as on.
- The log file is created only after an error occurs; a quiet page leaves it missing.
The wp-config.php block to paste
Open wp-config.php in the WordPress root — the folder holding wp-load.php — and paste four define lines above the comment that says to stop editing; constants placed below it are never read. This is the syntax given in the WordPress developer documentation:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );- Download a copy of wp-config.php first, using the cPanel File Manager, FTP or SSH.
- If a WP_DEBUG line already exists, change that line — a second define does not override the first.
- Save, reproduce the fault once, and check wp-content/debug.log for a line from that minute.
An empty file, or no file at all, means PHP raised nothing or could not write to wp-content. A plugin that toggles debug mode edits this same file, so open wp-config.php after activating one and confirm the three constants yourself, then remove it when the test ends.
How do you send errors to debug.log silently?
Set WP_DEBUG_LOG to true together with WP_DEBUG, keep WP_DEBUG_DISPLAY false, and add the display_errors line — WordPress then records the messages in wp-content/debug.log while visitors still see a normal page. WP_DEBUG_LOG does nothing on its own; it runs only when WP_DEBUG is also true.
The default file sits publicly reachable at /wp-content/debug.log until you delete it. To keep it private, set WP_DEBUG_LOG to a full path outside public_html instead of true; PHP must be allowed to create the file there. Silent logging is proven when the browser shows the ordinary page and the log has grown. How to read the lines — a fatal against a notice — is covered in how to read the WordPress debug log.
How do you debug a white screen of death?
A white screen means PHP stopped before WordPress printed any HTML, and the debug block records the fatal error as long as wp-config.php itself loaded. Work the log, not the blank page:
- Save the debug block, then load the blank URL once.
- Open wp-content/debug.log and read the last fatal — it names a file and a line number.
- Path under wp-content/plugins? Rename that plugin folder and reload; WordPress deactivates a plugin whose folder name changed.
- Path under wp-content/themes? Rename that theme folder and reload.
- debug.log never appeared? The failure is before WordPress, or wp-content is not writable — see PHP error logs when debug.log stays empty.
- Fix or update the code the fatal named, restore the folder name, retest, then turn debug off.
You have found the cause when the renamed folder makes the page render and the fatal does not return after the fix goes in.
When do you need SCRIPT_DEBUG or SAVEQUERIES?
SCRIPT_DEBUG is for scripts, not PHP faults: set to true it loads the development copies of core JavaScript and CSS instead of the .min.js and .min.css builds. Reach for it when the browser console points at a minified line you cannot read. You know it worked when the network panel requests jquery.js rather than jquery.min.js. Set it back to false afterwards — the full-size files slow every page — and note a plugin's own minified script changes only if that plugin honours the constant.
SAVEQUERIES is a different switch again. Set to true, it stores each database query of the request on $wpdb->queries and slows the page, so use it on a staging copy only, then restore false. It will not explain a white screen.
What if the fault happens before WordPress loads?
WP_DEBUG never runs when wp-config.php has a parse error — PHP stops before the constants — and the same applies when the limit is memory or execution time; those lines land in the account's PHP log, not debug.log. One value at a time, change memory_limit or max_execution_time, reload the failing URL, and undo anything that makes the log worse.
If your host provides cPanel, the MultiPHP INI Editor is the screen for these values: keep display_errors Off on a live site and log_errors On, then read the fresh line under Metrics → Errors. If you would rather hand the fault to a host that deals with WordPress for you, WebJi® WordPress hosting plans start at ₹400 a month before GST — email support@webji.services with the time of the test and the first fatal line, and the team reads it from there.
How do you turn debugging off after the fix?
Set WP_DEBUG back to false, remove the extra log, display, SCRIPT_DEBUG and SAVEQUERIES lines you added, delete wp-content/debug.log, and load one public page — logging is off when that visit does not recreate the file. A warning on every view can fill the account's disk quota, so switch the constant off before deleting a huge log, or the next view writes it again.
Never leave debug.log in place overnight on a live site. If the fatal persists, email support@webji.services the test time, the first fatal line and the plugin or theme folder named — no database passwords — in Hindi or English; the published average first reply is under 60 minutes.
Frequently asked questions
Where exactly do I add WP_DEBUG in wp-config.php?
In the WordPress root — the folder holding wp-load.php — place the define lines above the "stop editing" comment. Constants below that comment are never read. If a WP_DEBUG line already exists, edit that line; a duplicate define later in the file does not replace it.
Why does 'false' in quotes still enable debugging?
Because 'false' wrapped in quotes is a non-empty string, and PHP treats any non-empty string as true. The constants need bare booleans — true and false without quotes. This is the single most common reason a site keeps logging after someone tried to switch it off.
What does WP_DEBUG_LOG actually do?
While WP_DEBUG is true, it writes PHP errors, warnings and notices to wp-content/debug.log. Give it a full file path instead of true to store the log outside the public web root. With WP_DEBUG false it does nothing, and the file is created only after an error is raised.
Should WP_DEBUG stay on in production?
No. The default log sits in a publicly reachable folder and grows with every page view. For a short live test keep WP_DEBUG_DISPLAY false, copy the lines you need, then set WP_DEBUG back to false and delete debug.log the same day.
Why is debug.log never created?
The file appears only after PHP raises an error it can write to wp-content. A parse error inside wp-config.php stops PHP before the constants load, so nothing is logged. Check for a second WP_DEBUG line, confirm wp-content is writable, then read the account PHP error log instead.
Last editorial update: 15 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.