arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full facebook-box facebook loader magnify menu-down rss-box star twitter-box twitter white-balance-sunny window-close
Working on existing PHP applications
2 min read

Working on existing PHP applications

We’ve all been there before, you’ve been hired to finish / work on someone elses work, and you encounter some very strange behaviour. If you’re working on a small website, going through the code should provide you with the necessairy information to solve this issue, however, if the application is somewhat bigger (multiple components, databases, caching, dynamic code building, multiple objects …) it’s always nice to know exactly what code is being executed on a certain moment.

Imagine you have found the exact page / function / action where it’s going wrong, and you are trying to debug it. Commercial companies offer solutions like Zend Platform / Zend Studio to debug, view stacktraces, variable watches & alot more…and i am mostly using Zend Studio for that too, but at this moment in time, Zend does not offer a windows library for Zend Platform that supports PHP 5.2.0, neither did they release a fix for Zend Studio 5.5 to build inspectation data over a Samba share…So let’s do the same thing using XDebug, afterall the world still spins without Zend.
Make sure to get the right windows or linux module for your php version from www.xdebug.org and use the installation instructions to get it running, make sure to check phpinfo to see if the xdebug is loaded. When everything is installed, we’ll start by profiling a certain action to find out what exactly the page/action is doing. Make sure to adapt your php.ini with the following configuration :

zend_extension_ts=”c:/apache/php/ext/php_xdebug-2.0.0rc2-5.2.1.dll”

[xdebug]
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.profiler_append=0
xdebug.profiler_enable=1
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=c:/temp/
xdebug.profiler_output_name=profile

After that restart your apache, and open the page you want to analyse. As soon as you send a request to the webserver it will create a file in the c:/temp (or whatever path you defined). For me it generated a file (c:/temp/cachegrind.out.5808). This file contains alot of information what exactly php was doing on your request. Call it a stack trace. This file is human readable but does not give an immidiate overview, that’s why i would suggest to use a program to analyse the cachegrind. To my knowledge, the best program to-do that is KCacheGrind, the downside is that is a KDE program, so if you are using windows you would need alot of hacks, just to get KCacheGrind running, thats why there is a windows port (with less features) available called WinCacheGrind. If you open WinCache use the File>Open File dialog and relocate to the cachegrind.out file (for me c:/temp/cachegrind.out.5808), depending on the size of your file, wincachegrind will start analysing and give you a visual representation of the stack trace of your action.

Note that all pages you visit from now (untill de-activating the module in php.ini) will get ‘profiled’ and generate a cachegrind file. As this is filesystem intensive, i would suggest commenting the above php.ini section as soon as you’re done and restart your webserver.