What WP_DEBUG reveals (and what stays hidden)
WP_DEBUG is the WordPress constant that turns on PHP errors, warnings, notices, and deprecated-function messages. It does not show MySQL passwords, and it does not raise the memory limit. What stays hidden is whatever you turn off with WP_DEBUG_DISPLAY.
On a live site, log the messages and do not print them. Visitors should still see the theme. You open the log. A notice means PHP continued. A fatal means that request stopped.
| Constant | Value on 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 if WP_DEBUG is false. |
| WP_DEBUG_DISPLAY | false | Stops errors from printing in the HTML. |
| SCRIPT_DEBUG | false, unless you are reading core JS or CSS | Loads the unminified core scripts. |
| SAVEQUERIES | false | When true, stores each SQL query on $wpdb->queries and slows that request. |
- true and false are booleans. Quoting them, as in the word false inside quotes, makes a non-empty string, and PHP treats that string as on.
- The log file is created only after an error. A quiet page leaves it missing.
- A notice is not proof the page is broken. A fatal is the line that stopped the request.
The wp-config.php block to paste
Open wp-config.php in the WordPress root, the folder that also holds wp-load.php. Use cPanel File Manager, FTP, or SSH. Download a copy before you edit. Paste the block above the comment that says to stop editing. Constants below that comment are never read.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
If a WP_DEBUG line is already in the file, change that line. A second define does not override the first. true and false must be bare booleans. The word false inside quotes is a non-empty string, so PHP treats it as on.
A plugin that toggles debug mode edits this same file. Open wp-config.php after you activate it and confirm the three constants. Remove the plugin, or set the constants back, when the test ends.
You know the block is active when you reproduce the fault and wp-content/debug.log gains a line from that minute. An empty file, or no file, means PHP raised nothing or could not write the folder.
Sending errors to debug.log silently
WP_DEBUG_LOG set to true stores those messages in wp-content/debug.log. It runs only when WP_DEBUG is also true. Set WP_DEBUG_DISPLAY to false and add the display_errors line so the HTML stays clean.
The file is on the public site 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 that file. A quoted false does not turn the log off.
You know silent logging worked when the browser shows the normal page and the log grew. Line types, including a fatal versus a notice, are covered in how to read the WordPress debug log.
White screen of death — debug it step by step
A white screen means PHP stopped before WordPress printed HTML. The debug block records the fatal when wp-config.php itself loaded.
- 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.
- If the path is under wp-content/plugins, rename that plugin folder and reload. WordPress deactivates a plugin whose folder name changed.
- If the path is under wp-content/themes, rename that theme folder and reload.
- If debug.log never appears, the failure is before WordPress, or wp-content is not writable. Open the PHP error logs when debug.log stays empty.
- Update or remove the code the fatal named, put the folder name back, and retest. Then turn debug off.
You know the cause when the renamed folder makes the page render, and the same fatal does not return after you restore the folder with the fix in place.
SCRIPT_DEBUG for plugin and script issues
SCRIPT_DEBUG set to true makes WordPress load the development copies of core JavaScript and CSS instead of the minified files. Use it when the browser console points at a .min.js line you cannot read, or when you are editing those core files. It does not log PHP errors.
Leave it false for a normal PHP fault. The extra file size slows every page. A plugin's own minified script changes only if that plugin checks the constant. Set SCRIPT_DEBUG back to false when the script is fixed. You know it worked when the network panel requests the non-minified core file, such as jquery.js rather than jquery.min.js.
SAVEQUERIES is a different switch. Set to true, it stores each database query for that request on $wpdb->queries and slows the page. Use it on a staging copy only, then set it back to false. It will not explain a white screen.
PHP-level errors beyond WP — php.ini
WP_DEBUG never runs if wp-config.php has a parse error, because PHP stops before the constants. The same is true when the limit is memory or execution time. Those lines are in the account PHP log, not in debug.log.
On cPanel, open MultiPHP INI Editor for the domain. Keep display_errors Off on a live site and log_errors On. Change memory_limit or max_execution_time one value at a time, reload the failing URL, and undo the change if the new log line is worse.
You know the ini change applied when cPanel, then Metrics, then Errors, shows a line from that minute. WordPress hosting on WebJi includes that cPanel screen, so you can collect the line before you email.
Turning it all off after the fix
Set WP_DEBUG back to false and remove the log, display, SCRIPT_DEBUG, and SAVEQUERIES lines you added. Delete wp-content/debug.log. Load any public page once. You know logging is off when that visit does not recreate the file.
A warning on every view can fill the account quota. Turn the constant off before you delete a huge log, or the next view writes it again. Do not leave the file in place overnight on a live site.
If the fatal remains, email support@webji.services the time of the test, the first fatal line, and the plugin or theme folder. Do not include the database password. The office number +91-141-4941811 is not a support line. The average first reply is under 60 minutes, in Hindi or English.
WP_DEBUG questions
How do I enable debugging in WordPress?
In wp-config.php, above the stop-editing comment, set WP_DEBUG and WP_DEBUG_LOG to the boolean true and WP_DEBUG_DISPLAY to false. Save, reload the broken page once, and open wp-content/debug.log. A line from that minute means debug mode is on.
Where do I add WP_DEBUG in wp-config.php?
In the WordPress root, the same folder as wp-load.php. Put the define above the comment that tells you to stop editing. If the line already exists, change it. A later duplicate does not replace the first value PHP already set.
What does WP_DEBUG_LOG do?
When WP_DEBUG is true, it writes PHP errors, warnings, and notices to wp-content/debug.log. Set it to a file path instead of true to store that file outside the public site. It does nothing while WP_DEBUG is false.
How do I see errors behind a white screen?
Save the debug block, reload the blank URL once, and read the last fatal in wp-content/debug.log. Rename the plugin or theme folder that path names, then reload. If the file never appears, read the account PHP error log. The screen stays blank while display is off.
Should WP_DEBUG be on in production?
Not after the test. The log sits in a public folder and can grow without a limit. Keep WP_DEBUG_DISPLAY false during a short test, copy the lines you need, set WP_DEBUG back to false, and delete debug.log.
What is SCRIPT_DEBUG used for?
It loads readable core JavaScript and CSS instead of the minified copies. Use it when the console points at a .min.js line. It does not log PHP errors. Set it back to false when the script is fixed.
Why does a quoted false still enable WP_DEBUG?
The word false inside quotes is a non-empty string, and PHP treats that string as on. Use the bare boolean false, with no quotes, and keep only one WP_DEBUG line.
What if debug.log is not created?
The file appears only after PHP raises an error and can write to wp-content. A parse error in wp-config.php never reaches the constant. Check for a second WP_DEBUG line and then open the account PHP error log.