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

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.

In this article, I will show you how to use PHP 5 input filters to support debug, trace and assert statements so that a one-line change disables these statements and restores your script to full production performance.

He makes a custom solution, a simple method for just outputting simple debug statements via his own custom debugging classes - thDebug, theTrace and thAssert. He wraps all of these in a thDebugManager class to make them all play nice together.

With these in place, he moves on to the real key to the debugger, using the input filter extension that comes with PHP5. He makes a thAbstractStreamFilter abstract class to base the filtering on and, using this interface, makes his thDebugFilter class to handle the various debugging outputs. He uses the __autoload functionality to load it correctly into each page that needs it.

he bad news: mysqlnd might have bugs. How to report and debug these bugs - using mysqli_debug() - is subject of this posting.

They step you through the process for finding out what's causing the problems (internal versus external debugging) and how to make client traces with the mysqi extension to make it even easier for the developers to track down the problem. They also suggest a few things to send along with your bug report - like the PHP code calling it or the SQL you're using to select/update/insert/delete the data from your database.

Davey is a full time PHP Developer with 10 years experience in PHP and related technologies. An avid author for both magazines and books author, Davey keeps his mind sharp by trying to tackle problems from a unique perspective. Today Davey is going to show us how to debug Ajax applications using Firebug and the Zend Developer toolbar.

You can grab the video [mov] directly from the ZDZ site or subscribe to their feed to get this and other great podcasts.

So what have I concluded out of all of this? As clearly as I can state it here is the big problem. With Zend Studio 5.1 you could install Studio Server with no additional fee outside of the Zend Studio license. This allows you to debug via your local Apache instance running PHP. To get the same feature set out of Zend Studio 5.5 you would have to buy Zend Platform separate.

My hunch is the folks at Zend expect developers to debug on their local desktops with only the internal debugger which *can* produce different behavior than that under your web server environment. It's not good if your debugger can exhibit different behavior than your web server. I should also note that remote debugging with Zend Studio 5.1 while serviceable was not the most stable. It would occasionally kill Apache, possibly require me to restart Zend Studio or rare cases even force me to reboot.

He also lists out some of the other issues he's noticed in making the change (six of them).

He (Manuel Lemos) comes into the review not having dealt with Delphi before and having not created desktop applications before and found things a little overwhelming. He goes through the functionality of the application, including the structure of the applications you create (made up of "units" of PHP scripts). He gives a pretty comprehensive overview of what you can expect from the interface and a bit on some of the external functionality too - like the debugging.

For a first version of this PHP IDE, I think Borland/CodeGear did very well, but there is plenty of room for improvement. If you have been a big fan of Delphi for Windows desktop applications, you will certainly love Delphi for PHP.

Even if you dislike the choices that were made when it comes to the generated code or the library packages, Delphi for PHP may still be very useful for developers that need to quickly create a prototype of a PHP application and show how it looks to potential or current customers.

You can get more information, including features and pricing information from the official page on the CodeGear website.

For long-term reasons (it's a large multi-year project) and to provide more comfort for our customer (internal monitoring) and the communication from us (the development team) to the external entities (internal/external consumers of the webservice), we decided to improve the debugging capabilities of the SOAP service.

They give a code example of how to use this extension functionality. The script is set to make a request to a remote server and store all of the response information in an easy to use standardized error handling functionality.

Making mistakes is human, and so is fixing them. In your day-to-day programming adventures, it's inevitable to introduce bugs in your PHP code, especially when you're writing very complex applications with tens of thousands of lines of code spread across tens of files.

In this article they look at things like flattening if statements, spplitting single commands across multiple lines, and the difference between =, ==, and ===.