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.

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.

PhpStorm had it's share of trouble as well [with debugging], but yesterday I experienced a working debug session. Just like that, deep variable inspection and stepping through the code just worked. Today I looked into CLI debugging because Robert needed that for some complicated FLOW3 task. Also works, although it requires one step that should not be needed.

He points out the environment he's using and the two methods/setups he has for debugging - working through the browser and debugging command line scripts with the same tool. Some screenshots are included to help you be sure you're in the right place to change the settings.

It's basically a heavily improved var_dump and debug_backtrace version with some advanced behind the scenes action. The features description is in the google code page: http://code.google.com/p/kint/ but the interesting part is that this is the only dump tool, that can display the name of the dumped variable as well as use modifiers on the calling function.

The flow is traced back to its origin class/script and a token parser is used to find where the value was created. You can see a sample of how to use it over on its Google Code page. This also includes screenshots of the output and the configuration values you can set for things like a display path callback and the maximum number of levels to traverse through. You can download the current version here.

Few tasks are more tedious and frustrating than debugging a Web application. [...] Fortunately, PHP developers have a number of powerful debugging solutions at their disposal. Whether you're merely inspecting array contents or attempting to determine the status of an Ajax-driven POST response, these four solutions are guaranteed to have an immediate impact on your productivity.

His four solutions involve changing the error reporting level on your development environment higher than production to catch issues that might slip through unnoticed, using XDebug, integrating FirePHP and using test-driven development to be sure things work from the outset.

I am planning to write a series of blog post which will be helpful in debugging WINCACHE. This is just the beginning. So please be patient and forgive me if some of the posts sound for novice user. All my post will assume that you are debugging PHP CGI running under IIS using FastCGI. This means using the non thread safe version of PHP/WINCACHE and IIS running PHP files successfully. I believe the same can be applied to thread safe version of WINCACHE/PHP running under Apache but I do not guarantee that.

He mentions his build environment, what you'll need as far as software to debug and the WinCache source to build from. He includes brief instructions on building WinCache (vis Visual Studio) and how to set up the debugging for the PHP CGI. You can then attach the debugger in Visual Studio to the CGI instance and keep a watchful eye on it. You could also use the Windows Debugging Tools to do most of the same work.

In this fourth installment of the PHP Specificity series I'm going to break from the theme of content management packages momentarily and get into a topic that is not so dear to the programmer's heart. Debugging is a necessary evil and can be painful at times. But the reward, when it happens, is that eureka moment when you find the bug and squash it.

He mentions two helpful tools - DBG (though dead?) and the very popular XDebug that includes a profiler with Cachegrind output.

The @-operator is often used to silence errors in noisy PHP functions'"functions that generate warnings that can not be easily prevented. [...] In those cases, there is no way how to check up-front whether the function call will not issue a warning when being called.

There are side effects to using the operator, however, including hiding legitimate errors and making debugging that much more difficult. To back up his point, he includes four other reasons to avoid the operator's use (besides the debugging issues):

• It's slow (part 1)
• It's slow (part 2)
• It's slow (part 3: It generates crappier code)
• Apfelstrudels were harmed (related to the strudel_token in the C code for the operator)

Zend Platform is a powerful tool both in development and in production. [...] One of the cool features of it is the Event Debugger. Here's a short screencast that demonstrates how it works and how it integrates with Zend Studio for Eclipse.

The screencast is only about three and a half minutes long, but they cram a lot of screenshots and output results into that time. Cal Evans himself does the narration.

There is one thing I do need over everything else: remote debugging. Having used Zend Studio for 3 years now it hasn't been the best editor ( I'd rather prefer PHPEclipse/PDT ) but the remote debugging facility is superb [...] Eclipse it has all the tools you need to develop with but the debugging is slow, way too slow!

He's looking for anyone out there that might be able to help him speed up the debugging on his Leopard-installed version of Eclipse ("So slow actually that I had to install Zend Studio 5.5 for whenever I have to debug a file...")