Debugging 101

[Weedpacket]

Bung Xdebug onto your server

The Xdebug extension from PECL is something to go on your development server. It boosts PHP's error reporting with a lot more information about what it was doing when the fault occurred.

[matto]

Hi all,

there have been a few suggestions in this thread regarding how to benefit from var_dump and print_r. Over the years I've come to the following dumping functions which are available in all of my PHP projects and are quite handy.

Simply spoken, "vd" means "var_dump" only that is shorter and more useful.
"vdd" means "var_dump and die" - stops execution immediatly after output.

/**
 * vd functions version 1.1 by matto
 *
 * dump any object
 * set return_it to true so the dump will be returned as a string
 * otherwise it will be dumped to the screen
 * html_entities filter will be applied
 *
 * @param mixed $anobject, boolean return_it
 */
function vd($anobject, $return_it=false)
{
        ob_start();
        var_dump($anobject);
        $out = ob_get_contents();
        ob_end_clean();

        if(!$return_it)
        {
                echo "<pre>";
                echo htmlentities($out);
                echo "</pre>";
        }
        else
        {
                return htmlentities($out);
        }
}

function vdd($anobject)
{
        vd($anobject);
        exit;
} 

Everything gets nicely formatted, HTML won't be interpreted, plus you can re-route output into a variable in order to collect it for later display. Hope you find it useful.

[Shrike]

Weedpacket mention Xdebug just above, which can also format the output of var_dump() for a browser. It also creates some process log files which can be analysed in KCacheGrind or the windows equivalent WinCacheGrind. Handy for finding code bottlenecks.

[Weedpacket]

"var_dump and die"

That reminds me; anyone else been thinking of PHP t-shirt slogans?

[Weedpacket]

Cut-and-paste code does not work

As the programmer, it is your responsibility to understand what your code is doing and what it is supposed to do; the computer is not capable of doing that for you. Taking chunks of other people's code and inserting them into yours without bothering to work out how to use them is a sure way of turning your code into an unworkable mess.

If it's a class, study its interface to see what it provides and then decide if you can use it to do what you're wanting. If it's just a fragment of code of the sort that is posted here to illustrate a solution, remember that it is just an illustration and not necessarily the real thing. Who knows what it will do when you run it? If you don't, you're in trouble.

[banzaimonkey]

Run PHP from the Command Line

Testing in a browser is handy for seeing HTML output, but a lot of other things are lost. If you run your script from the command line you can see whether or not PHP is "fixing" your code for you, particularly in the case of uninitiated variables that PHP sometimes handles on its own.

[crux_op]

Isn't that what E_STRICT is for... to make PHP throw an error for every uninitialized variable instead of doing 'magic' and producing a value on its own?

[philipolson]

When using (uninitialized) variables that do not exist, errors of level E_NOTICE are produced and you cannot stop the PHP voodoo magic (like making $foo[bar] turn bar into 'bar'), it happens, but to go along with the magic you can produce (and find) the errors if (when) you turn them on.

People are encouraged to log all errors instead of using display_errors = on but regardless the main goal here (on this specific subtopic of eliminating php errors) is to turn on ALL errors, test the code, and eliminate said errors.

error_reporting(E_ALL | E_STRICT); 

http://php.net/error-reporting
http://php.net/manual/ref.errorfunc.php#e-strict
http://php.net/set-error-handler

Wow, this thread is old :-)

[überfuzz]

I find print_r() very useful whiledebuging.

$a = /*???*/; If you're not 100% on what a variable/array contains
echo "<pre>";
print_r ($a);
echo "</pre>"; 

The out put will be quite understandable.

Edit: wops this hint was allready posted. Sorry!

[dougal85]

However, as an adition to print_r you can use print_r($var, true); so rather than displaying the output it returns it as a string.

This can be then used in an error log and is often very useful.

[NogDog]

Don't forget about debug_backtrace() and debug_print_backtrace().

[reddrum]

These simple functions are a big help while developing. Set the DEBUG function to false when in production.

<html>
<head>
<title>Debug Output</title>
<body>

<?php
   arrayLog(DEBUG(), "This is Post", $_POST);
   outputLog(DEBUG(), "This is txtOne", $_POST['txtOne']);
?>

<form name="frm1" action="#" method="post">
   <input type="text" name="txtOne" />
   <input type="submit" name="isSubmit" value="Submit" />
</form>
</body>
</head>

</html>
<?php
function DEBUG(){
   return true;
}

function arrayLog($debug, $msg, $theArray){
   if($debug){
      echo "<pre>".$msg.": ";
      print_r($theArray);
      echo "</pre>";
   }
}

function outputLog($debug, $msg, $output){
   if($debug){
      echo "<br />".$msg.": ".$output."<br />";
   }
}

?>

[laserlight]

These simple functions are a big help while developing. Set the DEBUG function to false when in production.

It might be easier to use a defined constant instead of a function.

[reddrum]

Improved version:

   define("DEBUG", true);

   function outputLog($debug, $msg, $output){
      if($debug){
         if(is_array($output)){
            echo "<pre>".$msg.": ";
            print_r($output);
            echo "</pre>";
         }else{
            echo "<br />".$msg.": ".$output."<br />";
         }
      }
   } 

[mrbaseball34]

If using Firefox and Firebug, you REALLY should try the new FirePHP plugin.
http://www.firephp.org/