Today it has been ten years since the first release of Xdebug: version 0.7.0. I would like to celebrate this tenth anniversary with a new release: Xdebug 2.2.0. Xdebug 2.2 adds support for PHP 5.4 and provides some new features.

There's five new things on his list of updates in this latest release:

• Colours on the command line
• Better support for closures in stack and function traces
• The size of arrays is now shown with the overloaded variable output
• Added the method call type to xdebug_get_function_stack
• Extra information to error printouts to tell that the error suppression operator has been ignored due to xdebug.scream

If you've found XDebug handy for testing and finding those tough to track bugs over the years, you should consider buying "support" to show Derick your appreciation (oh, and you also get a "first in" preference on your XDebug questions)!

Debugging locally is a nice improvement to have no debugger at all, but in many situations there is the need to debug on production server, where the application is running on the web. There are different reasons for that, but the most important one for me is, that my local environment / installation is different from the one i have on servers in data center and bugs can be related to the environment.

He walks you through the installation and server-side configuration of XDebug first then shows how to install the Komodo Remote Debugging Client to help with multi-user debugging setups. He mentions setting up the debugging on the client/IDE side, but there's no specific instructions for any particular IDE - just how it works overall.

A profiler gives you the ability to trace the performance of your code through every function call and create an overview of your system's performance over a certain time period and helps you make intelligent decisions about where to look for problems. [...] But what if you're in an environment where you can't install [the xdebug or xhprof] extension? Luckily, php has a built-in function called register_tick_function that gives you a way to hook in to every user function that's called. With this, you can write a profiler yourself.

A bit of sample code illustrates his method - it defines a "do_profile" function and assigns it with the register_tick_function call. This function generates a debug backtrace and echos out the function path it took to get to that spot (output is included). He provides code for a bit more useful profiling and points out that it could easily be graphed to help visualize the problems. Also included are a few caveats to watch out for when using this method of profiling.

Doing development on multiple projects can be a burden from time to time. One project would be running on PHP 5.3, while another still needs 5.1. Sometimes you need a MySQL server, while on other occasions, you need a NoSQL solution like couchDB or MongoDB together with all kind of gearman functionality. This article shows you how I've setup such a development platform that allows you to quickly create new projects, and still maintain flexibility when you need it.

He uses VirtualBox with either a Debian or CentOS installation as a base platform. He uses Vagrant to set up and configure the machines to make setup almost automatic. He still has to go in and configure a few things like the VirtualHost and DNS settings for the site/application he's working on. Next up is setting up the tools he uses, specifically XDebug and setting up his editor of choice (PHPStorm) for remote debugging.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.

Whether you are an experienced developer or just getting started it is important to know how to measure the performance of your scripts and applications so that you can learn to make improvements and optimizations to your code. [...] This article compares two of the most popular [profiling] solutions under free license that you can begin using today to profile your PHP applications.

They describe each of the tools - the Quick PHP Profiler acting more like a plugin (running on each page load) and Xdebug working more behind the scenes and providing cachegrind files. These files can be viewed in cachegrind tools to drill in to the badly performing aspects of your applications and find the issues.

If you need a free tool it can be difficult to find a PHP profiling tool that has all of the features you may want and the interface that you like all rolled into one. Identifying what kind of data you are looking for and what information you need from a profiling tool will allow you to choose the best solution for your needs.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

PHP is very well used scripting language in now a days. But PHP does not have any inbuilt debugging tools or extension. But we have some extensions and tools available which serves the debugging purpose of the PHP.

The tools on their list involve both the backend and frontend:

• XDebug
• Zend Debugger
• FirePHP
• PHP Console

For the past 18 months working with PHP, i've primarily used alternatives, not out of preference, but because netbeans xdebug integration consistently failed me. It would (might) work with a remote apache, but would not play with scripts executed remotely from the command line. I could be fairly sure my xdebug config was sound as I no problems with MacGDB and PHPStorm whatsoever.

With a little more investigation, he discovered that it was the OSX firewall causing issues. He found that, with a new incoming connection came a confirmation box to approve the connection. This, of course, wasn't passed along to Netbeans so he never saw it. In the end, he set up a reverse SSH tunnel to bypass the firewall completely (command included).

The PHP debugging extension Xdebug has "remote" debugging capabilities for single-step debugging PHP applications. This works by setting your favourite IDE into listening mode and instructing Xdebug (with one of the handy browser extensions for example) to initiate debugging. [...] There could however be a firewall in the way that prevents Xdebug connecting directly to your IDE's IP address. That can be because the network you are on employs NAT. [...] In this case, there is no way Xdebug can connect to your IDE's IP address and port. Or is there?

His alternative requires SSH access to the remote machine - building a tunnel from your local machine to the remote server XDebug can use to get around the firewall. He explains the shell command to set up the tunnel and, a more graphical way, through the Putty ssh/telnet client. A quick call to "netstat" can tell you if things are working correctly or not. All that's left then is to point your XDebug to the port on the localhost and you should be good to go on debugging.