Print

Enable WordPress Debug Log

This article explains how to activate the WordPress debug mode and the WordPress debug.log file. You found this article because you likely experience a fatal error or a blank white page on your WordPress site. You can use WP Staging to prevent such fatal errors on your production site!

You may get an error 500 or a blank page when you open your WordPress website. To determine which plugin or broken code is causing that error, you can tell WordPress to write the errors into a log file or show them on the screen instead of showing just the white blank page. For doing that, WordPress offers the ability to activate the “debug mode” and getting all errors written into a file named “debug.log.”

How to activate WordPress Debug Mode

You can enable the WordPress “debug mode” by editing a few lines in the wp-config.php file of your WordPress installation.

To enable debugging mode in WordPress, follow the steps:

  1. Login to cPanel or log in to your site via FTP
  2. Use the cPanel File Manager or your FTP client and edit the file wp-config.php
  3. Add the lines below to the wp-config.php or if they already exist change their values:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Attention: Make sure that you write the lines exactly as shown.
Do not forget any semicolon or other characters!

After reloading the website, WordPress writes all PHP errors into the file debug.log. WordPress writes that file into the folder: wp-content/debug.log

If you want to see the debug log errors directly on the screen instead of needing to look into the debug.log change WP_DEBUG_DISPLAY to
define( 'WP_DEBUG_DISPLAY', true );

When we ask you to do so, please send us the debug.log file.
This file helps us to resolve issues you have with WP Staging.

WordPress Debug.log wp-config.php
How to activate the WordPress debug mode and write errors into debug.log

WordPress Does not Create the Debug Log

Some hosting providers[1] do not create the WordPress debug.log at all. They catch all errors and warnings which are created by WordPress and write them into a separate log file.

If WordPress does not generate the debug.log, check if there is another file in the root directory of your website, such as error_log or a folder named /logs or similar.

If you do not see any error logs at all, please ask your hosting provider where they store the log files.

Alternatively, you can try to set in the wp-config.php
define( 'WP_DEBUG_DISPLAY', true);

If this works, you will see the relevant errors on the front end. That will help you to resolve the fatal error which you get, but this should be used only in the last instance. Your visitors should not see such PHP error messages for security purposes. If you do not need it any longer, make sure to switch the value back to false.

You find more detailed instructions about how to enable the WordPress “debug” mode at https://codex.wordpress.org/Debugging_in_WordPress

At the time of writing this article: [1] HostGator

Change the Location of the debug.log

You can change the position of written errors by changing the value of the constant WP_DEBUG_LOG from true to a path of your choice like so:

define('WP_DEBUG_LOG', ABSPATH . '/logs/errors.log');

That allows you to write the error messages into another file located elsewhere and even enable you to write errors to dev/stderr or /dev/stdout.
That can be helpful if you use Docker or another development environment and want to have all your logs in a common location.

Disable Debug Mode in WordPress After Troubleshooting

We already mentioned this before, but If you are investigating WordPress website issues with the debugging mode, don’t leave it activated all the time. After using the debug.log, delete the file and disable further logging. Otherwise, unauthorized persons could access that file and would be able to get sensitive information from your server.

Always disable the WordPress debugging mode when you’re finished with investigating and troubleshooting your website issues.
Updated on September 17, 2020