How do you debug PHP scripts?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

print_r( debug_backtrace() );

or something like that :-)

Answer 4

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.

Answer 5

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.

Answer 6

+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>';
print_r($arrayOrObject);

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

Answer 7

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.

Answer 8

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.

Answer 9

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

echo "<pre>";
print_r();
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.

Answer 10

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

Answer 11

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.

Answer 12

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.

Answer 13

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

Answer 14

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 $$.

Answer 15

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.

Answer 16

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.

Answer 17

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

Answer 18

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

Answer 19

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

Answer 20

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>";

Answer 21

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.

Answer 22

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();

Answer 23

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.

Answer 24

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');
set_error_handler('error_handler');
set_exception_handler('exception_handler');
register_shutdown_function('shutdown_handler');

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) {
  return;
 }

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

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

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) {
  exception_handler($e);
 }
}

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

Answer 25

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)

Answer 26

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->log('xxxx');

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

Answer 27

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.