Debugging WordPress code can be difficult with just 'echo' calls - enable debug mode so that you can get complete access to variables even when they don't produce any output.
Update: Since WordPress 5.1 WP_DEBUG_LOG can be set to a file path. If set to true it will write to wp-content/debug.log; if set to a path it will write to that location. This allows you write to a file that is not web accessible.
WordPress is a significant product and debugging code can be difficult with just ‘echo’ calls. For this reason I frequently enable WordPress debug mode to see PHP warnings and notices and to log these messages to a file.
All my sites and client sites are on shared hosting so I cannot connect a debugger to them while I develop the sites. I have considered developing locally but I would have to push changes to external staging sites for clients to review. The overhead of that has discouraged me from going this route.
Enable Debug Mode
The first step is to enable debug mode. I just enable it for my IP address so that I don’t disrupt the browsing of others.
To demonstrate that it is working you can enable a tiny plugin – don’t forget to activate it.
Then browse the site and visit the sample post and page. You will see something like the following in wp-content/debug.log:
Once it is set up then you can add error_log() calls to your code. I use var_export($var, true) to display the value of complex variables or simple variables that may have non-printable characters.
Securing debug.log
With debug mode and WP_DEBUG_LOG enabled the wp-content/debug.log is now open to everyone. Warning messages may give a hacker insight for exploitable vulnerabilities. So, we must prevent that. You can use .htaccess to limit access to the file or set WP_DEBUG_LOG to a file path.
Create wp-content/.htaccess to limit access to wp-content/debug.log to just you.
Debugging Example
While working on my Override Woocommerce template files in a plugin post I had to investigate the information provided to the wc_get_template filter in the wc_get_template() function. I needed to determine whether the filter provided a full or relative path in the $located parameter and what was in the $template_name parameter.
I wrote a small plugin to write this information to debug.log:
There was a lot of data from the plugin, primarily from the $args parameter. Here is a short example of the information related to the “notices/notice.php” template.
I could quickly see that $located is the full path and $template_name is a short version.
Conditional Debug Messages
If you wish you can add error_log() calls throughout your code and set them to only run when WordPress is in debug mode.
Thanks for your article. Simple useful ideas! i use this little function :
var_error_log( $variable, 'text');function var_error_log( $object = null , $string = null){ ob_start(); // start buffer capture if (isset($string) && is_string($string)) echo 'START * * *'.$string." \n "; var_dump( $object ); // dump the values if (isset($string) && is_string($string)) echo 'END * * *'. $string." \n "; $contents = ob_get_contents(); // put the buffer into a variable ob_end_clean(); // end capture error_log( $contents ); // log contents of the result of var_dump( $object ) }
Thanks for the code. (One day I will fix the display of code snippets in comments)