Overview

On occasions, low level WordPress debugging is required to help narrow down issues. These problems can range from errors on the page to simply seeing a white page without any content. The verbose WordPress debug logs provide more information than what’s usually provided and this information can help to narrow down where the issue is.

Note

Ensure you delete the debug file once complete.

If you have access to Plesk, you can simply follow our guide on enabling WordPress debugging via the WordPress Toolkit.

Instructions

The first step is to always check the log files. Most standard Apache / Nginx based hosting platforms will have both access and error logs. As we use Plesk, we have access to a handy log viewer within the main control panel to view these logs.

Warnings (shown in yellow) should be addressed but generally won’t cause hard faults. Errors (shown in red) are the most critical and will generally result in a page failure.

If this doesn’t help narrow down the issue, we can turn on some of the internal WordPress debugging so that we can get more information. To do this, we’ll need to edit and insert the following lines into the wp-config.php file:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Note

We highly recommend doing this in a dev or staging environment, so that you don’t impact your production site.

By default, this will store the logs in the wp-content/debug.log file, and will contain fairly verbose data about what your WordPress site (including themes and plugins) is actually doing.

If you have SSH access to your server, you can now watch this in real-time by doing a ‘tail’ of the debug log:

tail -f wp-content/debug.log

This should give you fairly verbose output of any issues which are occurring. You’ll need to carefully inspect each error to determine the root cause. Sometimes it may not give you the exact line number or file, but the function in which the error occurred. By searching for this function in your themes and plugins, you should be able to trace to the error quickly.

Once you’ve (hopefully!) found and resolved the error, don’t forget to disable the additional debugging. You can simply comment these out with a hash (#) so you can quickly enable it again in the future. We also recommend deleting the debug.log to reduce any potential information leakage.

If the issue wasn’t resolved, we recommend trying the Query Monitor plugin, which provides detailed information on all database queries as well as AJAX, REST and function calls.

Official Docs: https://codex.wordpress.org/Debugging_in_WordPress

Was this article helpful?
Yes No

Related Articles