Sometime debugging PHP applications isn't as easy as just pointing your IDE directly at the server and starting to work. Derick Rethans has a new post talking about one such situation, remote debugging with a firewall in between you and the remote machine with XDebug.

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.

Karsten Dambekalns has a new post to his blog today about how he was able to get the PHP IDE PHPStorm and XDebug working together to do some debugging in his application.

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.

One of the more difficult parts of development is debugging. Any tool that can help make your bug finding life simpler can be valuable. Raveren has submitted a new tool he's developed to make outputting your debugging information more useful - Kint.

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.

On PHPBuilder.com today there's a new article from Jason Gilmore sharing what he calls "four sane solutions" to help you debug your PHP applications better than just an echo or var_dump.

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.

On the Windows IIS blog today Don Raman looks at debugging WinCache (the Windows caching tool with hooks into PHP) with Visual Studio - Basic in the FastCGI version on IIS.

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.

Douglas Clifton has the next part of his "PHP Specificity" series posted today - a brief look at debugging in PHP applications.

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.

Derick Rethans has posted just a few of the reasons why the "shut-up operator" (the @ symbol) should be avoided at all costs in your PHP applications.

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)

The Zend Developer Zone as posted a new screencast from Zend about the event debugging functionality offered with their Zend Platform product.

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.

Havard Eide is asking for your help in a new entry to his blog. He's looking for ways to speed up his development in Eclipse, specifically in the debugging.

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...")

Curt Zirzow has pointed out a cool article on the Box.net website about debugging your PHP applications with a combination of Vim and XDebug (on linux).

Here's how it works. You're coding away in vim. You hit F5; Vim waits for a connection from the PHP server. You refresh the PHP page you're working on. It attempts to contact Vim - connection successful. You are launched into a debugging session right inside Vim. You can step into, over, and out of statements, eval statements, get all variables in context, get and set properties, remove and set breakpoints, all on the fly. Finally, some real programming tools.

Included are the steps to set up the vim environment , set up the client debugger (DGBp) and link it all to the XDebug functionality on your remote machine.