View PHP errors in WordPress by enabling wp-debug mode
WordPress is a PHP based Content Management System (CMS). It's likely that at some point you'll need to fault-find a PHP error. Modern versions of WordPress usually show "There has been a critical error on this website" and email the site administrator a recovery link. Older versions - and some failures still - simply output a blank white screen, often called the white screen of death.
There are a number of places to look for information that might help you pin-point what's causing the problem. This includes the PHP and error_log files.
WordPress also has a PHP debug option that can be set within your wp-config.php file - normally found in the web root directory of your site.
Edit wp-config.php and find the following line - it will normally be set to false and should never be set to true on a live site unless you are fixing an error - after which it should be set back to false again:
define( 'WP_DEBUG', false );
To turn on PHP error display change this line to:
define( 'WP_DEBUG', true );
PHP errors will now be printed into the page - and not just for you. Every visitor sees them, including the full paths to files on the server. Note that this overrides our own server setting, which normally hides script errors from the public, so switching this on genuinely does expose them. Only do it on a live site if you have no alternative, and switch it back the moment you are finished.
If the WP_DEBUG line doesn't exist you can add it anywhere above the line that begins /* That's all, stop editing! - the rest of that line differs between WordPress versions, so search for just that much.
There are other options you can set to do things like turn debugging on - but write errors to a file instead of to the screen. In the following example setting WP_DEBUG_LOG to true causes the errors to be written to wp-content/debug.log.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
wp-content/debug.log sits inside your website, and anyone who guesses that address can download it - we have confirmed that .log files are served on our platform. The file records stack traces, full server paths and, when a database query fails, parts of your database configuration.So when you have finished troubleshooting: set
WP_DEBUG back to false, and delete wp-content/debug.log. Turning debugging off stops new entries but leaves the existing file sitting there.If you would rather it were never public in the first place,
WP_DEBUG_LOG also accepts a file path instead of true - point it somewhere above public_html and the log is written outside your website entirely.If you would rather these files were never reachable at all, you can block them yourself. Create or edit a .htaccess file in your public_html folder and add:
<FilesMatch "\.(log|sql|bak)$">
Require all denied
</FilesMatch>
Requests for any .log, .sql or .bak file below that folder then return a 403 instead of the file. Database dumps and editor backups are worth covering for the same reason as the debug log. We have tested this on our servers and it does not affect anything else on your site - but as with any .htaccess change, load your site once afterwards to be sure.
You may see SCRIPT_DEBUG suggested alongside these. It is unrelated to PHP errors - it makes WordPress load the unminified versions of its own CSS and JavaScript, which is useful when debugging a theme or plugin's front-end code but makes your pages heavier. Leave it out unless that is what you are chasing.
Additional options can be found in this WordPress.org article - Debugging in WordPress.
