Today we are going to test DebugPress, a recently released WordPress plugin to investigate possible problems with your installation.
One of the advantages of WordPress is that the amount of modifications you can make to a new installation is almost infinite. But this may also be a double-edged sword. The more complex a WordPress installation is, the easier it is to have incompatibilities and potential problems, and the harder it is to find them.
Installing and Configuring DebugPress
DebugPress is a WordPress plugin developer by Milan Petrovic that you can find in the WordPress.org plugin directory. This means that you can go to your WordPress installation, access the Plugins menu and there add a new one. Just by searching for the keyword “DebugPress,” you will find the plugin and you can download and activate it from there.
Once you have it activated in your WordPress, go to the DebugPress settings (within the Settings menu) to configure the plugin:
DebugPress Settings, Part I. DebugPress Settings, Part II.
Among the things you can modify, you have the ability to limit which user roles can access the DebugPress panel. You can also decide which additional panels to activate. In my case, I have activated them all in my test installation.
In the same way, I have enabled DebugPress to track all PHP errors and alerts, as well as AJAX calls and other options. Also, in order for DebugPress to be able to display information about SQL queries and activity in the WordPress error log, I have defined the following constants in the wp-config.php file of my installation:
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
define('SAVEQUERIES', true);I had already defined the first two constants before, as I am testing DebugPress on my development and test installation. If you’re a developer, I recommend you also define them, as you should probably be interested in getting as much feedback as possible from WordPress (by default, it hides them all).
The other two constants activate the error log (a debug.log file that is stored in the /wp-content/ folder of your installation) and the query storage we talked about. Note that you may not define these constants, but then some DebugPress panels will not display as much information as possible.
When you have everything ready, you can go to the icon of the bug that appears in the upper right corner of your WordPress. This icon will appear both in the WordPress Dashboard and when you access the frontend of your website (you can change the latter in the DebugPress settings).
There DebugPress provides you with information about your WordPress installation and what is happening when you access the frontend of your website.
The DebugPress information panels
When we click on the DebugPress button, a popup opens with several panels grouped in tabs. Each tab contains the specific panels of a particular type of information. Let’s see each of them and what information they contain.
In the first tab we have the basic information about our WordPress installation. Here we can see the PHP memory and execution time limits, the WordPress version, and the most important directories of the installation, as well as the value of some WordPress conditional tags to know if the installation is multisite, among other things.
Further, in DebugPress you have page load statistics. This is especially useful to see if the page has taken longer than expected to load, as well as to find out the number of SQL queries that have been made, the number of hooks that have been executed, and the memory that PHP has used.
In the DebugPress Request tab we have information about the current request that has been made to the WordPress server. We can see the URL that has been requested, as well as the headers of both the request and the response. Again, this is especially useful to see if both the information in the request and the response obtained are correct and have no problems.
In the Admin tab you have data about the current page of the WordPress Dashboard. When accessing the editorial calendar of Nelio Content in my installation I can see the value of the variable $pagenow as well as the values of the current screen:
One of the most interesting tabs in DebugPress is Content. Here you can see the entire list of custom post types registered in WordPress, as well as custom taxonomies and post statuses. Also, you can expand each of these types and see the values they have.
In the Constants tab we have all the constants defined in WordPress. Furthermore, for each defined constant we can see its value at this precise moment:
In the SQL Queries tab of DebugPress we can see at any given moment which SQL queries have been executed to display the current page. In addition to seeing each of these queries, we can order them by their execution time and thus have at a glance which queries are the slowest, as well as the PHP functions that called them.
If you have a plugin that does strange things with the database and makes your website go much slower, with this view you will be able to identify the source of your problems.
In the DebugPress User tab we have all the information of the current user. This includes both the information that we can find in the wp_users table and in the wp_usermeta table of the WordPress database.
If you do not have access to the database and you need to see the role of your user and the specific capabilities that have been assigned to you, this panel will be very useful.
Another interesting DebugPress panel is the one that shows you all the styles and scripts that are enqueued in WordPress on a specific page. Many times we have had problems with users of some of our plugins because our JavaScript scripts were not loaded during their installation. Having this information is of special interest to developers like us.
Now we can ask those users who are more reluctant to give us access to their WordPress installation to install DebugPress and share with us a screenshot of the Enqueue tab to see if there are scripts that are not loading as they should. Troubleshooting with this information should be easier.
In the PHP panel we can see the information contained in the PHP variables $_SERVER, $_REQUEST, and $_COOKIE for the request of the current page:
Also, in the System tab we have general information about the WordPress server. It is important here to be able to see the version of PHP you’re using, the server IP, and some limits on the upload size and the execution time:
Finally, in the AJAX tab we see the AJAX calls that are executed on the current page. In this view I have to say that I have not found interesting things: if you have access to the WordPress installation, what you can find about AJAX calls in the developer console of the browser itself is much more interesting than what DebugPress shows here.
Finally, next to the button to close the DebugPress window that we find in the upper right corner, we see there is a button shaped like a sheet of paper. This button opens the view in which we can see the WordPress log that we activated at the beginning.
Here we see where the log is stored in the installation and the size of the file. You can use the big blue button to load the log file, but I’m afraid I wasn’t able to do so.
Every time I click on this blue button an AJAX request is launched by DebugPress, which returns an error. We can see this failed request in DebugPress’s own AJAX tab.
If I open the WordPress log file with any text editor I see that there is an error in DebugPress that occurs when I click that button. So I guess right now this version of DebugPress has a bug that the developer will fix in future versions.
Still, this has been the only downside that I have been able to find after thoroughly testing the different views and panels DebugPress provides.
Nelio Content
I’m so happy about Nelio Content that I will sound like a payed advocate… but here’s why you’ll love it: it works as promised, its auto-scheduling feature is top-notch, Nelio’s value for money is unmatched, and the support team feels like your own.
Panozk
Opinion on DebugPress
Although all the information that DebugPress provides us can be consulted through other means, having it all in one place is the most valuable thing of this plugin.
Obviously, DebugPress is not a plugin to keep activate all the time in your WordPress, but it can be of great help when you have to investigate possible problems in the installation of a client of which you do not have much idea why they are happening. Hopefully, DebugPress can help you guess what problems are and from there pull the thread to fix your WordPress.
With DebugPress you have all the necessary information so that finding problems in WordPress is a little easier. I hope they fix the problems they have with the log and thus improve even more the quality of this plugin, totally recommended for WordPress developers.
Featured image by Xuan Nguyen on Unsplash.
Leave a Reply