![]() ![]() Turning our Clever Debugger into a Function Dump x, or any other variable for that matter I found this code snippet a few years ago in a post that explained how to dump var_dump into a file, and it goes like this: $x = "My string" Now suppose we do not have an error string or any string at all, but we want to check the values of certain variables, as we do with var_dump. You write: error_log( "I'm on line 38") How to Log Variables Instead of var_dump ![]() Now, instead of using the echo command to log your variables, you use the error_log PHP command. This creates an error.log file and places it in the wp-content folder. ![]() The solution is turning on both wp_debug and wp_debug_log in wp-config.php, – i.e., setting them both to true. Sometimes the reason is clear – for example when creating a widget and something goes wrong during the save method, echo to the screen won’t work because the function uses AJAX, thus refreshing the part of the widget to which you’d be echo-ing… Other times, the reason might be unclear – you just get some fatal error that does not allow the page to render, and your echo just doesn’t show up on the screen… Either way, whether the reason is clear or not, the result is the same and you must find a different way to display values of the variables in question. But, sometimes, these commands cannot be used. Writing Your Own Messages to the Log File, or When echo Doesn’t Cut itĭuring the process of locating an error, one of the most convenient ways to debug is by using echo and var_dump. This could happen if the server’s php.ini file has display_errors set to 1. You sometimes might need to add this line in order to hide the errors from the screen. Disable display of errors and warnings Enable Debug logging to the /wp-content/debug.log file Disable display of errors and warningsĪnd so, the set of commands that enables us to send error messages to a file and not to the screen is this: // Enable WP_DEBUG mode The next thing to do is not to allow errors to be written on the screen. Now you might ask yourself who’s going to create that log file and where will it reside? The answer is that WordPress takes care of this for us, i.e., no need for our manual creation: as soon as an error comes up, a log file is created, and is placed in the wp-content folder. That way, the tracked errors are written to a log file. The WordPress Codex documents a solution to this problem, under the entry How to debug WordPress:Īfter turning on WP_DEBUG, turn on WP_DEBUG_LOG. Introduction to WP_DEBUG_DISPLAY and WP_DEBUG_LOG ![]() So how can we catch bugs that happen in production? Is there a way to see the debug info without sharing it with the site visitors? Indeed there is, and that’s where other constants defined in wp-config.php come into play. Doing this during the development phase of the project is highly recommended since it shows you the bugs in your code while you’re developing, and you can fix them right away.īut what if you want to check errors on a production site? Displaying errors on the screen is the last thing you want to do, since it not only disturbs the site’s appearance, it can also be a source of information leak. To start debugging, go to the wp-config.php file in the root of the WordPress file system and turn on the debug variable, i.e., set debug to true: define( 'WP_DEBUG', true ) ĭefining this constant as true will cause all PHP errors, notices, and warnings to be displayed on the screen. Get to know a few plugins that enhance the debugging experience.Learn how to log all the SQL queries run on a page,.Learn how to use the un-minified JavaScript and CSS core files for debugging purposes,.See how to write debug messages to a log file and where that file is located.Debugging WordPress starts with WP_DEBUG, but can go far beyond that. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |