TamWiki

(redirected from Main.HowToSetUpForDebuggingInPHP)

Debugging PHP can be a major pain. If you're not using something like Xdebug, typically, debugging PHP is done via printing out variables and state information to the browser as your application is running. Turning debugging on and off is sometimes a major pain. I've devised scheme to make it much simpler.

Also, see the section on php.net about debugging.

Using the query string or post vars

My scheme uses the query string or post vars on any PHP script call to include the parameter debug=true. Thus to call a script and turn on debugging, one could use http://www.example.com/myscript.php?debug=true.

To set this up, I include the following in my config.inc.php file, which gets called at the beginning of every script in the application:

As you can see, this set the global debug to true or false depending on the existence and value of the debug parameter on either the query string or from the post data or from the environment. The $additional_query_parms is an array to keep track of any additional query or post info that might be needed to add to redirect urls or urls in the emitted html code, thus allowing the debug flag to be set once and perpetuated to other script calls.

Then, I set up a couple of functions (in a file I usually call functions.inc.php which gets included by config.inc.php in every script):

Notice that the string is output wrapped by DEBUGPREFIX and DEBUGSUFFIX defined above to make it apparent this is debugging code. (The constants are typically defined in the config.inc.php file before the include of function.inc.php.)

debug() let's you print out a string of info with an optional variable, as well as the current file and line number. If the variable is an array, it gets formatted by the print_r(). To call debug, place a line similar to:

The function takes care of checking whether the DEBUG flag is set on, so you can simply embed the debugging calls into your script and forget about them. I tend to leave the debugging calls in until I've thoroughly tested the code. Code under development seems to work better with debugging things left in.

Thus, in many cases, I have something like the following at the front of every script:

Just to see what is getting passed into each script. If a configuration file gets included early, I'll usually just throw those two lines in there.

The problem with redirects when debugging

Oftentimes, one script will do some processing and then redirect to another script to finish up and display the actual results. When debugging, you don't always want this to happen so you can see what's going on on the page you're working on without losing the potential debugging out when a page redirects.

Thus, I've come up with the following function to handle those situations:

The effect of the above function is to create a redirect string then when debugging, print out the redirect string and a link to the redirect and exit. When not debugging, the redirect happens the normal way.

The buildredirect() function is a nice utility for creating useful redirects with additional query attributes. See HandlingRedirectsInPHP.

Advanced Debugging Features

The above is great for doing rudimentary debugging in a straight-forward fashion. Sometimes, though, you want to do things a bit more precisely to keep things neat within an application.

As such, I've written a debug class script (Attach:class.debug.phps Δ that can be included in the application to handle debugging in a more interesting fashion.

Place this into a common include file, such as config.inc.php:

By default, this will turn debugging on, use HTML in debug output, use the standard error logging facility, emit output directly, and use a standard prefix and suffix for the debugging output.

Then, to make debug statements, insert the line:

where you want your debug output to appear.

The class contains a number of methods, which are documented in the source file.