DebugPress will work regardless of the WordPress settings, but some things will not work if WordPress is not set up correctly. Two major issues will be related to error logging and SQL queries.
Debugger Error Logging
The Debugger can intercept all PHP errors (well, it can’t intercept fatal errors because they will stop page loading). WordPress uses WP_DEBUG constant to enable or disable PHP error reporting, and if the error reporting is disabled, Debugger can’t catch any errors. So, we need to tell WordPress to enable the debug mode. But, at the same time, to hide errors from displaying on the page.
So, open wp-config.php, and find line where WP_DEBUG is set and replace it with:
define('WP_DEBUG', true); define('WP_DEBUG_DISPLAY', false); define('WP_DEBUG_LOG', true);
The last line is not really needed, it tells WP to log all errors into the file too, and it can be useful for later analysis. Also, for AJAX calls, DebugPress will also store in this error log pointers where each AJAX request starts and ends, so you can easily find which errors belong to individual AJAX calls.
Debug log created by WordPress is called ‘debug.log‘ inside the ‘wp-content‘ directory.
SQL Queries Debugging
By default, WordPress is not saving SQL queries it executes, even if the debug mode is enabled. So, if that is not done, Debugger can’t display the SQL Queries tab and allow you to analyze them. To turn on SQL queries saving, add one more line after the WP_DEBUG block.
Despite what you might read, this is a very useful thing to have always active, it will not take any significant memory, and will help you with page loading analysis.
In case you can’t make changes to the wp-config.php file, the plugin has two options to attempt to automatically enable both debug mode and saving of queries. If you decide to use these options, SQL queries run before the SAVEQUERIES is set by the plugin will not be logged, and any error happening before the plugin is loaded will not be logged. That is why it is best to enable these via wp-config.php.