About debug on WordPress
Debug code must be the part of development process. This amplifies the final product quality and increases interoperability with the ecosystem of WordPress, ie the core, plugins in question and the subject in use.
Make your WordPress site’s Load Blazing Fast Just by moving to Nestify. Migrate your WooCommerce Store or WordPress Website NOW.
So consider the development of projects with the active debug and revised to avoid hidden errors, warnings, alerts and warnings codes. On the run, or in the absence of development planning, the debug is left in hand, quality and safety gets hit, and unfortunately produces a poor, insecure and flawed code.
Debug safely, the three constants and two functions
Natively, we have a debug system that, by default, is disabled. Besides the possibility of activation, we have hidden capabilities for power and greater security mechanism.
The constant WP_DEBUG
The debug can be enabled by constant WP_DEBUG wp-config.php file.
1 define( ‘WP_DEBUG’, false ); // By default is disabled
2 define( ‘WP_DEBUG’, true ); // Consider the true value to enable
The other configuration options are listed below:
1 define( ‘WP_DEBUG_LOG’, true );
2 define( ‘WP_DEBUG_DISPLAY’, false );
The constant WP_DEBUG_LOG
Through constant WP_DEBUG_LOG, we get all warnings and alerts, errors and warnings saved codes in a file called debug.log, which is located in /wp-content/debug.log.
This file should be reviewed at regular intervals and inconsistencies of all application codes should be analyzed and then everything should be brought to the team knowledge for the solution. In addition, this procedure is a great ally for off-screen situations analysis where the processing takes place in AJAX requests and Cron feature of WordPress, for example.
The constant WP_DEBUG_DISPLAY
The value of true and / or false can and should be considered for constant WP_DEBUG_DISPLAY. Its default value is true, which means that errors are displayed on the screen – the same value should be considered in development environments.
Production environments should be kept constant with a value of false, thereby preventing the display of the screen where error implementation details are exposed.
We advise the use of false value for all environments, but in conjunction with the true value to the constant WP_DEBUG_LOG. Thus, we will not have the errors on the screen, avoiding environmental exposure and in some cases, compromising the implementation of the interface, and forcing the team to review the debug.log file for analysis and correction of inconsistencies.
The values of the constants are aligned in the PHP settings
1 define( ‘WP_DEBUG’, true );
2 define( ‘WP_DEBUG_LOG’, true );
3 @ini_set( ‘log_errors’, ‘On’ );
4 define( ‘WP_DEBUG_DISPLAY’, false );
5 @ini_set( ‘display_errors’, ‘Off’ );
With this combination of constants and values, we guarantee an ideal setting for a safe and effective debug in WordPress, recording and storing the inconsistencies, but avoiding its exposure.
Attention is drawn to the use of ini_set PHP, used to define the value of a setting. It is important to them in addition to the constant WP, to make sure that the desired behavior for the application is aligned with the PHP behavior configured on the server.
For example, imagine that PHP was configured to display errors, and the display_errors directive in php.ini file with the On value and the constant WP_DEBUG_DISPLAY is the false value to not to display errors. The behavior set in PHP will override the WP, so both align and avoid surprises.
In addition to the hidden errors, warnings and alerts and warnings codes:
WordPress modify, improve, add and remove new functions and their arguments with every released version. But there is a clear policy of maintaining legacy code, so security and consistency to the use of new versions and maintain old code. So consider keeping WordPress and its components up to date.
The functions and their arguments that were out of favor in the WP are treated specially. First, there is no break and inconsistency. For a few releases, cycle is maintained for compatibility with the legacy system. Second, warnings are issued when it makes use of unused code, stating that they have been modified in the correct x and the version to be used from now is another function / argument and that in a not too distant future how to use cease be supported.
These warnings are recorded in debug.log, thus allowing the consultation by the developer of the new way to go further. Ie, WordPress, and maintain compatibility, detailing the code passed to be fixed.
Location and protection of debug.log file
As reported, the debug.log file is located in the / wp-content, this file in any way must be public and, therefore, we need to protect it.
The correct permission for the file
Consider allowing 600 to debug.log file that allows reading and recording core of WordPress and its plugins to the file.
A contribution to .htaccess
Besides the correct permission, for those using Apache, consider extra protection to the file through directives in .htaccess, and block external access to the file through the web browser – for example, when someone tries to access the field-of-site. com / wp-content / debug.log.
1 <Files debug.log>
2 Order allow,deny
3 Deny from all
4 </Files>
Consider using the standard WordPress debug mechanism, but make safe use through the constant and correct functions for this. Ensure safety and better quality of developed and updated code of the platform.
Note:
If you are looking for Managed WordPress Hosting that is isolated from other users on the server, We provides you with everything for which you have been waiting for. Our hosting is built on a blazing-fast SSD latest hardware That’s Highly tuned for optimum performance. The hosting includes daily backups, anytime money back, 99.97% uptime and 24×7 support.
