How do you debug your PHP script?

I am aware of basic debugging such as using the Error Reporting. The breakpoint debugging in PHPEclipse is also quite useful. Any other good/better techniques out there?

+5  A: 

I've used the Zend Studio (5.5), together with Zend Platform. That gives proper debugging, breakpoints/stepping over the code etc., although at a price.

Michael Stum
+25  A: 

I follow the article at http://dev.piwik.org/trac/wiki/HowToSetupDevelopmentEnvironmentWindows to setup an Eclipse environment that has debugging features like you mentioned. The ability to step into the code is a much better way to debug then the old method of var_dump and print at various points to see where your flow goes wrong. When all else fails though and all I have is SSH and vim I still var_dump()/die() to find where the code goes south.

John Downey
print_r( debug_backtrace() );

or something like that :-)

Orion Edwards
+3  A: 

Xdebug, by Derick Rethans, is very good. I used it some time ago and found it was not so easy to install. Once you're done, you won't understand how you managed without it :-)

There is a good article on Zend Developer Zone (installing on Linux doesn't seem any easier) and even a Firefox plugin, which I never used.

Christian Lescuyer
Its not just installing that's frustrating. Configuring Xdebug to work with Eclipse can be a nightmare. I was able to get Xdebug installed on CentOS 5 but EclipsePDT+Xdebug dont want to co-operate :(
+4  A: 

In all honesty, a combination of print and print_r() to print out the variables. I know that many prefer to use other more advanced methods but I find this the easiest to use.

I will say that I didn't fully appreciate this until I did some Microprocessor programming at Uni and was not able to use even this.

I am glad you mentioned print as well as print_r, I use a basic print to see if the code executed to a certain point, which helps isolating the problem.
I use both print and var_dump(). I use print to display debug messages and information and var_dump to indicate the state of variables as things progress.
Good Time Tribe

+1 for print_r(). Use it to dump out the contents of an object or variable. To make it more readable, do it with a pre tag so you don't need to view source.

echo '<pre>';

Also var_dump($thing) - this is very useful to see the type of subthings

+20  A: 

You can use Firephp an add-on to firebug to debug php in the same environment as javascript.

I also use Xdebug mentioned earlier for profiling php.


Depending on the issue I like a combination of error_reporting(E_ALL) mixed with echo tests (to find the offending line/file the error happened in initally; you KNOW it's not always the line/file php tells you right?), IDE brace matching (to resolve "Parse error: syntax error, unexpected $end" issues), and print_r(); exit; dumps (real programmers view the source ;p).

You also can't beat phpdebug (check sourceforge) with "memory_get_usage();" and "memory_get_peak_usage();" to find the problem areas.

Eric Lamb
+7  A: 

1) I use print_r(). In TextMate, I have a snippet for 'pre' which expands to this:

echo "<pre>";
echo "</pre>";

2) I use Xdebug, but haven't been able to get the GUI to work right on my Mac. It at least prints out a readable version of the stack trace.

I'm sure you mean echo "</pre>"; at the end though.
Yes, I did. Thanks for catching it! Now corrected.
You can also pass 'true' into the function so it returns the string. It means you can do this: `echo '<pre>', print_r($var, true), '</pre>';`

In a production environment, I log relevant data to the server's error log with error_log().

+2  A: 

i use zend studio for eclipse with the built in debugger. Its still slow compared to debugging with eclipse pdt with xdebug. Hopefully they will fix those issues, the speed has improved over the recent releases but still stepping over things takes 2-3 seconds. The zend firefox toolbar really makes things easy (debug next page, current page, etc). Also it provides a profiler that will benchmark your code and provide pie-charts, execution time, etc.

+3  A: 

For the really gritty problems that would be too time consuming to use print_r/echo to figure out I use my IDE's (PhpEd) debugging feature. Unlike other IDEs I've used, PhpEd requires pretty much no setup. the only reason I don't use it for any problems I encounter is that it's painfully slow. I'm not sure that slowness is specific to PhpEd or any php debugger. PhpEd is not free but I believe it uses one of the open-source debuggers (like XDebug previously mentioned) anyway. The benefit with PhpEd, again, is that it requires no setup which I have found really pretty tedious in the past.

The PHPEd debugger is actually written by the same guy who wrote PHPEd and I'm pretty sure it's not open source. At least PHPEd doesn't ship with the source but instead compiled .so's and .dll's.
Artem Russakovskii
+1  A: 

Manual debugging is generally quicker for me - var_dump() and debug_print_backtrace() are all the tools you need to arm your logic with.

+8  A: 

XDebug is essential for development. I install it before any other extension. It gives you stack traces on any error and you can enable profiling easily.

For a quick look at a data structure use var_dump(). Don't use print_r() because you'll have to surround it with <pre> and it only prints one var at a time.

<?php var_dump(__FILE__, __LINE__, $_REQUEST); ?>

For a real debugging environment the best I've found is Komodo IDE but it costs $$.

Julio César

Komodo IDE works well with xdebug, even for the remore debugging. It needs minimum amount of configuration. All you need is a version of php that Komodo can use locally to step through the code on a breakpoint. If you have the script imported into komodo project, then you can set breakpoints with a mouse-click just how you would set it inside eclipse for debugging a java program. Remote debugging is obviously more tricky to get it to work correctly ( you might have to map the remote url with a php script in your workspace ) than a local debugging setup which is pretty easy to configure if you are on a MAC or a linux desktop.


The integrated debuggers where you can watch the values of variable change as you step through code are really cool. They do, however, require software setup on the server and a certain amount of configuration on the client. Both of which require periodic maintenance to keep in good working order.

A print_r is easy to write and is guaranteed to work in any setup.

Michael Luton
+3  A: 

I use Netbeans with XDebug. Check it out at its website for docs on how to configure it. http://php.netbeans.org/

+7  A: 

Xdebug and the DBGp plugin for Notepad++ for heavy duty bug hunting, FirePHP for lightweight stuff. Quick and dirty? Nothing beats dBug.

Thanks for the link to dBug. It's pretty neat.
Wow. dBug is great! Thanks for the link
+2  A: 

PhpEdit has a built in debugger, but I usually end up using echo(); and print_r(); the old fashioned way!!

Toby Allen

Well, to some degree it depends on where things are going south. That's the first thing I try to isolate, and then I'll use echo/print_r() as necessary.

NB: You guys know that you can pass true as a second argument to print_r() and it'll return the output instead of printing it? E.g.:

echo "<pre>".print_r($var, true)."</pre>";
Nathan Strong
I just wrap that in a function called debug. So then I can do debug($var);

Usually I find create a custom log function able to save on file, store debug info, and eventually re-print on a common footer.

You can also override common Exception class, so that this type of debugging is semi-automated.

Joshi Spawnbrood
+2  A: 

Output buffering is very useful if you don't want to mess up your output. I do this in a one-liner which I can comment/uncomment at will

 ob_start();var_dump(); user_error(ob_get_contents()); ob_get_clean();
+5  A: 

PhpEd is really good. You can step into/over/out of functions. You can run ad-hoc code, inspect variables, change variables. It is amazing.

+3  A: 

This is my little debug environment:

error_reporting(E_ALL | E_STRICT);
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_BAIL, 0);
assert_options(ASSERT_QUIET_EVAL, 0);
assert_options(ASSERT_CALLBACK, 'assert_callcack');

function assert_callcack($file, $line, $message) {
 throw new Customizable_Exception($message, null, $file, $line);

function error_handler($errno, $error, $file, $line, $vars) {
 if ($errno === 0 || ($errno & error_reporting()) === 0) {

 throw new Customizable_Exception($error, $errno, $file, $line);

function exception_handler(Exception $e) {
 // Do what ever!
 echo '<pre>', print_r($e, true), '</pre>';

function shutdown_handler() {
 try {
  if (null !== $error = error_get_last()) {
   throw new Customizable_Exception($error['message'], $error['type'], $error['file'], $error['line']);
 } catch (Exception $e) {

class Customizable_Exception extends Exception {
 public function __construct($message = null, $code = null, $file = null, $line = null) {
  if ($code === null) {
  } else {
   parent::__construct($message, $code);
  if ($file !== null) {
   $this->file = $file;
  if ($line !== null) {
   $this->line = $line;

The most of bugs can be found easily by simply var_dumping some of key variables, but it obviously depends on what kind of application you develop.

For a more complex algorithms the step/breakpoint/watch functions are very helpful (if not necessary)

Petr Peller

I often use CakePHP when Rails isn't possible. To debug errors I usually find the error.log in the tmp folder and tail it in the terminal with the command...

tail -f app/tmp/logs/error.log

It give's you running dialog from cake of what is going on, which is pretty handy, if you want to output something to it mid code you can use.


This can usually give you a good idea of what is going on/wrong.

+1  A: 

I use Netbeans with XDebug and the Easy XDebug FireFox Add-on

The add-on is essential when you debug MVC projects, because the normal way XDebug runs in Netbeans is to register the dbug session via the url. With the add-on installed in FireFox, you would set your Netbeans project properties -> Run Configuratuion -> Advanced and select "Do Not Open Web Browser" You can now set your break points and start the debugging session with Ctrl-F5 as usual. Open FireFox and right-click the Add-on icon in the right bottom corner to start monitoring for breakpoints. When the code reaches the breakpoint it will stop and you can inspect your variable states and call-stack.