If you code, you will need to learn how to debug. PHP can be more difficult to debug than some languages because it lacks a built-in debugger, so you can't step through the code line by line and set break points. PHP also does not require that you declare your variables. The first time it comes across a variable, the variable is automatically typed and scoped. This behavior is both a blessing and a curse; it is guaranteed that you will have times when you will debug a script for hours, only to discover that the root cause was a misspelled variable name.
The following is a list of recommendations for more efficient PHP debugging:
This should be old news for anyone who has done web development of any kind, but you must ensure that you are getting the freshest copy each time you view a page. The one caveat here is with Firefox and its "Work Offline" setting. If you are developing locally on your own computer (for example, using MAMP) and you have disconnected from the Internet, Firefox tends to go into "Work Offline" mode, which means that it will not reload any pages. Make sure Firefox never enters the "Work Offline" mode.
Use the following settings in your php.ini file:
error_reporting = E_ALL display_errors = On
And optionally, use these settings to log errors to a log file:
log_errors = On error_log = "/path/to/php_error.log"
For security, make sure the following value is set:
register_globals = Off
This will make PHP print errors to the screen (and optionally to the logs), including line numbers. Without this type of verbose output, it is virtually impossible to tell if your scripts are having problems, let alone diagnose them. On a shared hosting environment, you may not have much control over the contents of the php.ini file, but you can include a line in your scripts to change the error reporting level:
error_reporting(E_ALL)
Some hosting setups allow you to use your own local php.ini file to override system settings found in the main php.ini file. Check with your web host for details.
WordPress has some debugging options of its own. If you are developing on a shared server where you cannot modify the php.ini file, it can be just as effective to modify the contents of your wp-config.php file so that the WP_DEBUG value is set to true:
define('WP_DEBUG', true);From a *nix command line (Linux or Mac OS X), you can easily check whether or not a script has parse errors by using the syntax-check flag:
php -l myscript.php
If you are using Coda on Mac OS X, you can install the PHP Toolkit (http://www.chipwreck.de) and check for syntax errors directly from Coda. No matter what, check your syntax frequently! Sometimes forgetting a semicolon or a bracket can trigger an error that is nowhere near the actual problem. So, it is best to work on one area of code at a time and check syntax frequently so you will know where to look for the problem.
Since PHP does not have a built-in debugger, it is common for developers to temporarily sprinkle their code with print and exit statements to check variable contents at runtime. You should become intimately familiar with the following two functions: print_r
and var_dump. The get_defined_vars() function is also useful to help check for misspellings and variables that may be persisting beyond the scope you expected.
It is common to exit your script after performing one of these debugging maneuvers, then comment out the statement once you've verified the values. It can be really easy to forget that you added an exit statement somewhere in your script, so be vigilant when you perform this type of debugging. Don't forget to comment it out when finished.
For example, the following script:
<?php
$arr = array('man','bear','pig');
print_r($arr);
?>prints this result, clearly identifying the contents of the array:
Array
(
[0] => man
[1] => bear
[2] => pig
)Tip
If you are doing any sort of frontend development that involves CSS or JavaScript, then the Firefox Firebug add-on is invaluable (http://getfirebug.com).
If you're not already a Firebug user, here's a little exercise that you can try in order to get a glimpse of the value that Firebug can do to aid in debugging. First, upload the following HTML file to the root of your site then visit it using Firefox (for example, http://yoursite.com/firebug.html):
<html>
<head>
<title>Testing FireBug</title>
<script type="text/javascript">
function myFunction(inputValue)
{
console.log('Current value is' + inputValue);
}
</script>
</head>
<body>
<a href="#" onclick="myFunction('man')">Man</a><br/>
<a href="#" onclick="myFunction('bear')">Bear</a><br/>
<a href="#" onclick="myFunction('pig')">Pig</a><br/>
</body>
</html>Within FireFox, click on the Firebug icon at the bottom-right corner of your browser to activate it, then enable the console. Do you see how you can track JavaScript variable values in the console?
Note
Note that the console.log() function has variants: console.info(), console.warn(), and console.error(). They all accept input in the same format at PHP's printf() function, and they will all help you test your JavaScript. The big thing to remember when using the Firebug console methods is that they are only available when Firebug is active. As soon as you close Firebug, those commands will fail and cause JavaScript processing to stop. The simple workaround is to remove the debugging statements when you are finished debugging, or shepherd them into areas where they can fail safely.
We will show some examples of how to use Firebug and JavaScript in your plugins in some of the later chapters.