Accepted answer

try eclipse pdt 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.


+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


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.


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.


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.


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


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.


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)


php dbg

the interactive stepthrough php debugger implemented as a sapi module which can give give you complete control over the environment without impacting the functionality or performance of your code. it aims to be a lightweight, powerful, easy to use debugging platform for php 5.4+ and it's shipped out-of-box with php 5.6.

features includes:

  • stepthrough debugging
  • flexible breakpoints (class method, function, file:line, address, opcode)
  • easy access to php with built-in eval()
  • easy access to currently executing code
  • userland api
  • sapi agnostic - easily integrated
  • php configuration file support
  • jit super globals - set your own!!
  • optional readline support - comfortable terminal operation
  • remote debugging support - bundled java gui
  • easy operation

see the screenshots:

php dbg - stepthrough debugging - screenshot

php dbg - stepthrough debugging - screenshot

home page:

php error - better error reporting for php

this is very easy to use library (actually a file) to debug your php scripts.

the only thing that you need to do is to include one file as below (at the beginning on your code):


then all errors will give you info such as backtrace, code context, function arguments, server variables, etc. for example:

php error | improve error reporting for php - screenshot of backtrace php error | improve error reporting for php - screenshot of backtrace php error | improve error reporting for php - screenshot of backtrace

features include:

  • trivial to use, it's just one file
  • errors displayed in the browser for normal and ajaxy requests
  • ajax requests are paused, allowing you to automatically re-run them
  • makes errors as strict as possible (encourages code quality, and tends to improve performance)
  • code snippets across the whole stack trace
  • provides more information (such as full function signatures)
  • fixes some error messages which are just plain wrong
  • syntax highlighting
  • looks pretty!
  • customization
  • manually turn it on and off
  • run specific sections without error reporting
  • ignore files allowing you to avoid highlighting code in your stack trace
  • application files; these are prioritized when an error strikes!

home page:


my fork (with extra fixes):


if your system supports dtrace dynamic tracing (installed by default on os x) and your php is compiled with the dtrace probes enabled (--enable-dtrace) which should be by default, this command can help you to debug php script with no time:

sudo dtrace -qn 'php*:::function-entry { printf("%y: php function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

so given the following alias has been added into your rc files (e.g. ~/.bashrc, ~/.bash_aliases):

alias trace-php='sudo dtrace -qn "php*:::function-entry { printf(\"%y: php function-entry:\t%s%s%s() in %s:%d\n\", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }"'

you may trace your script with easy to remember alias: trace-php.

here is more advanced dtrace script, just save it into dtruss-php.d, make it executable (chmod +x dtruss-php.d) and run:

#!/usr/sbin/dtrace -zs
# see:

#pragma d option quiet

    printf("%y: php compile-file-entry:\t%s (%s)\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1));

    printf("%y: php compile-file-return:\t%s (%s)\n", walltimestamp, basename(copyinstr(arg0)), basename(copyinstr(arg1)));

    printf("%y: php error message:\t%s in %s:%d\n", walltimestamp, copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);

    printf("%y: php exception-caught:\t%s\n", walltimestamp, copyinstr(arg0));

    printf("%y: php exception-thrown:\t%s\n", walltimestamp, copyinstr(arg0));

    printf("%y: php execute-entry:\t%s:%d\n", walltimestamp, basename(copyinstr(arg0)), (int)arg1);

    printf("%y: php execute-return:\t%s:%d\n", walltimestamp, basename(copyinstr(arg0)), (int)arg1);

    printf("%y: php function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);

    printf("%y: php function-return:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2);

    printf("%y: php request-shutdown:\t%s at %s via %s\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1), copyinstr(arg2));

    printf("%y, php request-startup:\t%s at %s via %s\n", walltimestamp, basename(copyinstr(arg0)), copyinstr(arg1), copyinstr(arg2));

home page: dtruss-lamp at github

here is simple usage:

  1. run: sudo dtruss-php.d.
  2. on another terminal run: php -r "phpinfo();".

to test that, you can go to any docroot with index.php and run php builtin server by:

php -s localhost:8080

after that you can access the site at http://localhost:8080/ (or choose whatever port is convenient for you). from there access some pages to see the trace output.

note: dtrace is available on os x by default, on linux you probably need dtrace4linux or check for some other alternatives.

see: using php and dtrace at


alternatively check for systemtap tracing by installing systemtap sdt development package (e.g. yum install systemtap-sdt-devel).

here is example script (all_probes.stp) for tracing all core php static probe points throughout the duration of a running php script with systemtap:

probe process("sapi/cli/php").provider("php").mark("compile__file__entry") {
    printf("probe compile__file__entry\n");
    printf("  compile_file %s\n", user_string($arg1));
    printf("  compile_file_translated %s\n", user_string($arg2));
probe process("sapi/cli/php").provider("php").mark("compile__file__return") {
    printf("probe compile__file__return\n");
    printf("  compile_file %s\n", user_string($arg1));
    printf("  compile_file_translated %s\n", user_string($arg2));
probe process("sapi/cli/php").provider("php").mark("error") {
    printf("probe error\n");
    printf("  errormsg %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
probe process("sapi/cli/php").provider("php").mark("exception__caught") {
    printf("probe exception__caught\n");
    printf("  classname %s\n", user_string($arg1));
probe process("sapi/cli/php").provider("php").mark("exception__thrown") {
    printf("probe exception__thrown\n");
    printf("  classname %s\n", user_string($arg1));
probe process("sapi/cli/php").provider("php").mark("execute__entry") {
    printf("probe execute__entry\n");
    printf("  request_file %s\n", user_string($arg1));
    printf("  lineno %d\n", $arg2);
probe process("sapi/cli/php").provider("php").mark("execute__return") {
    printf("probe execute__return\n");
    printf("  request_file %s\n", user_string($arg1));
    printf("  lineno %d\n", $arg2);
probe process("sapi/cli/php").provider("php").mark("function__entry") {
    printf("probe function__entry\n");
    printf("  function_name %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
    printf("  classname %s\n", user_string($arg4));
    printf("  scope %s\n", user_string($arg5));
probe process("sapi/cli/php").provider("php").mark("function__return") {
    printf("probe function__return: %s\n", user_string($arg1));
    printf(" function_name %s\n", user_string($arg1));
    printf("  request_file %s\n", user_string($arg2));
    printf("  lineno %d\n", $arg3);
    printf("  classname %s\n", user_string($arg4));
    printf("  scope %s\n", user_string($arg5));
probe process("sapi/cli/php").provider("php").mark("request__shutdown") {
    printf("probe request__shutdown\n");
    printf("  file %s\n", user_string($arg1));
    printf("  request_uri %s\n", user_string($arg2));
    printf("  request_method %s\n", user_string($arg3));
probe process("sapi/cli/php").provider("php").mark("request__startup") {
    printf("probe request__startup\n");
    printf("  file %s\n", user_string($arg1));
    printf("  request_uri %s\n", user_string($arg2));
    printf("  request_method %s\n", user_string($arg3));


stap -c 'sapi/cli/php test.php' all_probes.stp

see: using systemtap with php dtrace static probes at


print_r( debug_backtrace() );

or something like that :-)


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.


nusphere is also a good debugger for php nusphere


there are many php debugging techniques that can save you countless hours when coding. an effective but basic debugging technique is to simply turn on error reporting. another slightly more advanced technique involves using print statements, which can help pinpoint more elusive bugs by displaying what is actually going onto the screen. phpeclipse is an eclipse plug-in that can highlight common syntax errors and can be used in conjunction with a debugger to set breakpoints.

display_errors = off
error_reporting = e_all 
display_errors = on

and also used



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


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.


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


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.


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


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


i use netbeans with xdebug. check it out at its website for docs on how to configure it.


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.


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.


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.


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.


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.


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.


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


xdebug and the dbgp plugin for notepad++ for heavy duty bug hunting, firephp for lightweight stuff. quick and dirty? nothing beats dbug.


this is my little debug environment:

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;


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.

Related Query

More Query from same tag