By default, the WordPress debugging feature is disabled. You need to learn how to activate it and know the advanced options.
Do you know how to debug codes in WordPress? Encoding applications and websites requires constant debugging to ensure quality, performance, and smooth operation.
All language, framework and CMS have (or should have) mechanisms for this purpose.
WordPress and its plugins ecosystem provide us with simple and effective ways to debug codes.
Debugging code is extremely important, but only in a development environment, since in the production environment the rule is silence.
What we mean is that when you are designing your application, coding your codes on your machine, you need to display / record the errors that occur to act on them.
However, when the application is in use (published) these same errors should be hidden to the end user, since they expose information about your system – such as the vps web server version, the language version, the physical paths of the server – and which can be used by malicious users.
How to debug codes in WordPress
By default, the WordPress debugging feature is disabled.
It is activated through a constant located in the wp-config.php file.
This constant receives a boolean value true or false to enable or disable the feature, respectively. See the examples:
With the debug option enabled, errors will be displayed on the screen. Thus, the developer will be aware of its existence to act on its correction and, with this, ensure a better delivery.
The types of errors displayed
PHP error / alert messages informing about fatal errors, nonexistent indexes verified by empty (), isset () functions, among others;
WordPress debug messages reporting on the use of deprecated functions and
WordPress database error messages – from version 2.3.2 WordPress hides error messages from the database if the WP_DEBUG constant is set to false .
We particularly do not like to display errors on the screen, even in the development environment.
We have some good reasons for that. Think according to us:
We are human and susceptible to mistakes. Therefore, a deploy with the WP_DEBUG constant with the value true can occur . As we said above, the result is an exposure of environmentally sensitive data;
In AJAX requests we will not see any errors, if any. Unless you are monitoring through Firebug, for example and
Visually it is ugly and impacts the rendering of the website in the internet browser.
We said we do not like displaying the errors on the screen, but we really like debugging codes and guaranteeing quality.
So we add two other constants to work together that we know now.
These are the WP_DEBUG_LOG and WP_DEBUG_DISPLAY constants. Respectively, we assign the value true to one and false to another.
This will cause errors to be written to a log file and not displayed on the screen.
This file is called debug.log and gets armed in / wp-content.
If Apache – or the web server that is in use – does not have write permission, you need to create this file and set the appropriate permission that would be 0666.
Here’s an example code with these options enabled:
We hope that with these suggestions and examples you can more closely monitor the errors, work on your corrections and ensure a better delivery of your work.
There are other forms of debugging in WordPress, as well as plugins that help us in this matter, but for now we know a good way.