In computer programming debugging is a methodical process for finding and reducing the number of bugs. In simpler words, when code is not working as expected, we debug it to find out what is causing the issue and fix it.

Every programmer does debugging and there are many different methods. But the best way to debug is using debugger tools.
Have you ever had problems understanding third party libraries (e.g. Joomla core) and you had to var_dump in third party code?

Have you ever done this?

echo "I am here";
... some php code ...
echo "I am here, something is:";
var_dump($something);

This is called debug code and it's bad and generally sucks because you're mixing debug code with production code. What if you commit your debug code and it goes to production by mistake? Writing debug code is a very slow, inefficient, and energy consuming process as you have to actually write many lines of code to trace the program and control execution and to inspect the values.

You don't need to write debug code if you use a debugger as you will see what's happening in memory, step by step. Debugger tools give you the benefit of debugging in real time with no effort. Debuggers let you:

  • See errors, warning, notices, etc.
  • See stack trace (what is calling what, and on which line)
  • Do variable and memory inspection (instead of var_dump or print_r)
  • Follow the flow of program
  • Change the values in the memory in real time

Debuggers are awesome

Have you ever had a problem understanding how your code or a third party code (e.g. Joomla core) works? Have you ever experienced problems understanding why your code or any other third party’s code such as Joomla core is doing something? Debuggers help you resolve these problems.

Debuggers help unravelling Spaghetti Code. If you are having problems figuring out how the application actually works, you can set a breakpoint at the very first line that is executed and use the “Step Over” and “Step Into” buttons to follow the execution path taken by the application. This method helps tremendously in demystifying and clears up all the twists and turns that the code takes.

XDebug

Xdebug is a PHP extension which adds debugging and profiling capabilities to PHP.
In this next part of my blog, we’ll go through the steps to configure XDebug for PhpStorm and Vim.
The first step is to install XDebug on your development environment. Make sure you install the Xdebug zend extension.

Configuring PHP Storm

Once Xdebug is installed, All you need to do is add these to your .htaccess file:

php_value zend_extension <path to xdebug so library file>
php_flag xdebug.remote_enable on
php_value xdebug.remote_port 9000
php_value xdebug.idekey PHPSTORM-XDEBUG
php_value xdebug.remote_host <IP address of the machine running php storm>
php_flag xdebug.remote_connect_back on

Alternatively you can directly update your php.ini file.

For example in my .htaccess file I have:

php_value zend_extension /usr/lib/php5/20090626/xdebug.so
php_flag xdebug.remote_enable on
php_value xdebug.remote_port 9000
php_value xdebug.idekey PHPSTORM-XDEBUG
php_value xdebug.remote_host 192.168.56.1
php_flag xdebug.remote_connect_back on

Note that the IP address must be accessible by the machine running PHP. For example if you have a virtual box with a host only network, this IP address must be your windows machine IP in the host only network.

Running ipconfig on my windows command line I get:

ipconfig

Once the .htaccess file is updated, do the following in PhpStorm:

  1. Run->edit configuration
  2. Add a new remote debug
  3. You need to have configured a server. if you haven't click on the button text to servers list
    1. give it a name, host, port, and debugger
    2. use path mapping
    3. map your root to absolute path of the installation (not a symbolic link) e.g. /data/…/… /www
  4. Select your server
  5. Type in the session ide key from your .htaccess file
  6. Save

Start Debugging

The first thing you need to do is drop a breakpoint on the line of code you’d like to start debugging from. Then we can start debugging:

  1. Click on listen for debug connection
  2. Click on debug button
    debug-2
  3. Go to browser and go to your website URL. Make sure you add the session ID key and add the parameter:
    XDEBUG_SESSION_START=PHPSTORM-XDEBUG
    (e.g. http://<domain>/index.php?option=com_owcontactform&XDEBUG_SESSION_START=PHPSTORM-XDEBUG)
    debug-3

In PhpStorm Debugger you can use F8 to stop over, F7 to step into and F9 to continue.

  • You can also add a watch on a variable, jump to code, change the value of a variable, create conditional breakpoints, etc.

To finish debugging do the following:

  1. Click on the close button
  2. Click on stop listening for connection

Configuring Vim

Add the following to your .htaccess file:

php_value zend_extension <path to xdebug so library file>
php_flag xdebug.remote_enable on
php_value xdebug.remote_port 9000
php_value xdebug.idekey <your name>-VIM
php_value xdebug.remote_host localhost

In my .htaccess file I have:

php_value zend_extension /usr/lib/php5/20090626/xdebug.so
php_flag xdebug.remote_enable on
php_value xdebug.remote_port 9000
php_value xdebug.idekey ARASH-VIM
php_value xdebug.remote_host localhost

Install the vdebug plugin for Vim:

1. If you don’t have vundle, you need to install it first:

git clone https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle

2. vim ~/.vimrc and copy the following into your vimrc:

set nocompatible " be iMproved
filetype off " required!
set rtp+=~/.vim/bundle/vundle/
call vundle#rc()
" let Vundle manage Vundle
" required!
Bundle 'gmarik/vundle'
Bundle 'joonty/vdebug.git'

" My bundles here:
"
" original repos on GitHub
"Bundle 'tpope/vim-fugitive'
"Bundle 'Lokaltog/vim-easymotion'
"Bundle 'rstacruz/sparkup', {'rtp': 'vim/'}
"Bundle 'tpope/vim-rails.git'
" vim-scripts repos
"Bundle 'L9'
"Bundle 'FuzzyFinder'
" non-GitHub repos
"Bundle 'git://git.wincent.com/command-t.git'
" Git repos on your local machine (i.e. when working on your own plugin)
"Bundle 'file:///Users/gmarik/path/to/plugin'<br< a=""> />" ...

filetype plugin indent on " required!
"
" Brief help
" :BundleList - list configured bundles
" :BundleInstall(!) - install (update) bundles
" :BundleSearch(!) foo - search (or refresh cache first) for foo
" :BundleClean(!) - confirm (or auto-approve) removal of unused bundles
"
" see :h vundle for more details or wiki for FAQ
" NOTE: comments after Bundle commands are not allowed.

3. Then in your terminal type:

vim +BundleInstall +qall

Multi-user debugging

You can also set up a debugger for multiple developers working on same project.
For this to work, you will need to set up a DBGp proxy and you can find more information to help you with this here:
http://derickrethans.nl/debugging-with-multiple-users.html
And here:
http://xdebug.org/docs/remote

Start debugging – Vim debugging commands and shortcuts

  • To add a breakpoint on a line (:Breakpoint)
    vim-1
  • Remove breakpoint (:Breakpoint) again
  • Start debugging (F5)
  • Run to breakpoint (F5)
  • Show step over (F2)
  • Show step into (F3)
  • Show step out (F4)
  • Show stop debugging (F6) twice
  • Move to next window (ctrl+j and ctrl+k) depending on your vim configurations.
  • Switch on local global variable by going over [local] or [global] and pressing enter
  • Open arrays or variables by going over them and pressing entre
  • Stack trace (pressing enter will take you to the file)
    vim-2

You can also find more info here: https://github.com/joonty/vdebug
Or type this in Vim:

:help Vdebug

Other IDEs

Most other PHP IDEs also have a debugger (eclipse, Aptana, zend studios, netbeans, etc.)
You can also download plugins for sublime text:

Profiling

XDebug can also be used for profiling. It will dump profiling data which can then be opened with a profiling tool such as KCacheGrind.

Conclusion

Once you’ve used a debugger, you’ll never go back to writing debug code. Your life will become meaningless without them and you’ll wonder what you ever did before!

Debuggers definitely make debugging easier and less problematic. With the instructions above, you’re well on your way, but if you’re interested in additional resources on this topic, you can check out:

Go back to CMS