Last updated February 28, 2015. Created on May 20, 2008.
Edited by sidharrell, forestmonster, pwolanin. Log in to edit this page.

For advanced development a debugger may be very useful. A debugger will allow you to follow program execution and its effects, to observe the call stack of functions, and review the contents of variables at any point during execution.

Xdebug is the standard tool in PHP.

The main site:

Some articles on setting up and using it:

This Drupal module has additional tools for visualizing the Xdebug call traces:

For working in Drupal 8, you will need to add this line to the xdebug section of your php configuration, either in xdebug.ini or php.ini, if you are using a version of xdebug prior to 2.3:


The default nesting level of 100 causes issues. See and


I downloaded the php package from at For Mac 10.4 and 10.5 I have Xcode installed, which includes gcc and other necessary comilation-related packages.

To build I went to the directory (assuming you unpack the PHP source code archive in your home dir):


and ran:

$ ./pecl install xdebug

this built and placed it in the direcrtory:

For the particular combination of MAMP + Komodo IDE

For my version of MAMP I copied to the following dir
(final dir name may vary by PHP version):


make sure Zend optimizer is OFF in MAMP preferences.

Make sure to restart apache after making these changes to php.ini. After verifying the location of, add the following to your php.ini file (or perhaps /etc/php5/conf.d/xdebug.ini, depending on your operating system):



you can add this to .htaccess in your Drupal root or a parent dir:

php_value xdebug.remote_enable on

These (among others) may also be useful to add to .htaccess if you want to profile
memory usage:

php_value xdebug.auto_trace On
php_value xdebug.show_mem_delta On

To debug in Komodo, make sure Debug >> Listen for Debug Connections is enabled. In Drupal, add the query string: ?XDEBUG_SESSION_START=1 .

Alternatively, using the "easy Xdebug" extension for Firefox or the Xdebug helper for Chrome, you can initiate an Xdebug session with one click, instead of having to add the query string.

Looking for support? Visit the forums, or join #drupal-support in IRC.


Liberation’s picture

solipsist’s picture

You can follow these instructions (they apply to PDT):

Then use the compiled XDebug Shared Object binary which is available from ActiveState (works with PDT as well as Komodo):

Jakob Persson

Jakob Persson - blog
Leancept – Digital effect and innovation agency

Darren Oh’s picture

While debugging a Views 2 plugin, I found that Xdebug does not recognize breakpoints in files included by methods in objects. Since NetBeans supports only Xdebug, I was reluctantly forced to return to Eclipse PDT, which support the Zend debugger.

P.S. This page indicates that what Xdebug really has a problem with is files in different directories using the same name:

boaz_r’s picture

Your conclusions seems wrong to me. If your IDE + xDebug is configured correctly, you'll stop at every breakpoint in your project (I'm referring to PDT only here. Not experienced with Netbeans).
See the section titled "Eclipse PDT" in the guide you've just linked. If you configure "Path mapping" correctly, those break points will be regarded. See the second screenshot in that section I just mentioned. Make sure to use file path in the "Path on server" section. Using "http://..." as the path passes PDT validation but will cause PDT/xDebug to ignore your breakpoints altogether (aside from "break first line", if you use that nagging feature :-)


Therapeutic PHP sessions

dudym’s picture

I think this tip about mapping the server path to the PROJECT path of eclipse (and not the local directory like I did before) is precious.
It should be one of the first things one should check out if his/her breakpoints don't seem to work.

Hamon Toda,

thomasvum’s picture

I was able to install XDebug with Acquia Stack Installer on my OSX (localhost)

I downloaded XDebug (2.0.5) Source

unpacked it on my desktop.

opend Terminal and moved into the directory

cd /Users/yournamehere/Desktop/xdebug-2.0.5/xdebug-2.0.5

I followed the guide, except the downloading part:

I run phpize (NOT phpsize) ;-)


run the following commands

export MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"
export CCFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe"
export CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe"
export LDFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load"

./configure --enable-xdebug


now copy the /Desktop/xdebug-2.0.5/xdebug-2.0.5/modules/ Directory to your acquia php bin folder:

Now I have 2 files and

in /Applications/acquia-drupal/php/bin/modules/

Edit your php.ini
I used the AcquiaDrupalControlPanel
settings -> config -> edit php.ini

Add the following line to your php.ini


when you create a phpinfo(); page (

it should show something like

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans

and at the bottom xdebug variables

Now set up you programming enviroment with XDebug (another story.... working on it)


zzadik’s picture

I installed xdebug and the debugger steps in and breaks at break points I place at function declarations in my .module files.
The problem is that if I try to "Step into" the functions, the debugger jumps to the next function call, and doesn't allow me to debug the code inside each function.
I guess this is not a limitation of the debugger, but something I configured\doing wrong.

Any suggestions?

Mixologic’s picture

If you set your breakpoints *on* the function declaration line, the debugger will break on the function declaration lines when an 'include' or 'require once' steps through and compiles them. Try setting your breakpoint on the first line of the function you wish to debug, or even on the line in whatever file is calling that function. The debugger should stop on that line when its actually executing it and not merely adding it.

momo18’s picture

In Eclipse PDT I set a breakpoint at the top of node-product.tpl.php file, but the debugger never seems to stop in it, and I can't figure out why?

I am using xDebug and I'm wondering if there might be some reason I can't think of.

Second, for debugging in Drupal what should I be using? xDebug or the Zend debugger? Does it make any difference at all in terms of debugging?


lpeabody’s picture

I ran into this problem. If you're caching and not rebuilding the theme registry on every page load, this could occur.

joshtaylor’s picture

If you are using Drupal 8, you will need to up your xdebug.max_nesting_level setting to access node/add/page.