Derick Rethans has posted about some new browser extensions for the popular PHP-based debugger Xdebug. These are to replace the helper that is no longer available on FireFox's site (download).

Years ago I wrote about a Firefox extension that allows you to start an Xdebug debugging session by clicking on an icon in Firefox' status bar. For some unexplained reason, this extension is no longer available through Firefox' addon-site. [...] There are now a few other browser extensions that do the same thing.

He lists three new extensions that can most of what you'd need to keep your testing going - easy Xdebug, Xdebug enabler (for Chrome) and this blog post with a pure Javascript method done with bookmarklets.

Matthew Turland has put together a guide for getting PHPUnit and Xdebug up and working on one of the latest Ubuntu releases (Karmic) to resolve an upgrade issue with the package install.

This is just a quick post to advise anyone who may be using PHPUnit and Xdebug together on Ubuntu Karmic. If you try to upgrade to PHPUnit 3.4.6 and you're using the php5-xdebug Ubuntu package (which is Xdebug 2.0.4), you may get output that looks like [this error].

He gives a two ways to overcome the issue - forcing the PEAR installer to ignore dependencies or reinstalling with Xdebug 2.0.5 instead (via the PECL installer) as a shared module.

Davey Shafik has a quick tip for anyone trying to use Xdebug from the command line and finding themselves having issues.

Thanks to some help from Derick and my co-worker Trevor, I now have a simple bash script that will let me and my team easily debug CLI scripts on our development server.

The script is two lines (really just one) that uses a combination of environment variables, PHP's command line binary and a few other standard unix commands to parse the output of the request. The script can be made executable and dropped into a place in your path to make it as simple as running "xdebug file.php" on the file.

Derick Rethans has a new post today talking about using the Xdebug tool to track the memory usage in your application with some of its profiling capabilities, specifically function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it.

He's written up a sample script (you can grab it from the Xdebug CVS server) that you can run on a file and push all ouf the output to the trace file for easy parsing. The script reads in the file and displays the results in a nice format on the command-line (easily adaptable for a web frontend).

On the Think Vitamin blog Kieran Masterson has put together an article about debugging PHP applications - everything from error levels out to a few useful tools that can help with some of the more complex issues.

Nobody enjoys the process of debugging their code. If you want to build killer web apps though, it's vital that you understand the process thoroughly. This article breaks down the fundamentals of debugging in PHP, helps you understand PHP's error messages and introduces you to some useful tools to help make the process a little less painful.

He looks at changing the display_errors setting, updating the error_reporting level, the types of errors (notice, warning, etc) and the Xdebug and FirePHP tools.

On the Affinity Bridge blog today there's a great post looking at the use of Xdebug and KCachegrind to pinpoint bottlenecks and possible refectoring points in your code in a bit more visual way. They use an example from their own development - a script that took around twenty minutes to run.

By reducing the number of queries, making small code optimizations, and properly indexing and keying the legacy database we managed to cut the time to 10 minutes'"still we were way off target. To get a better look at what was going on, we thought it would be great to install Xdebug and take a look at it with KCacheGrind.

They show you how to get the full setup installed (on a Ubuntu system) - the LAMP stack, Xdebug and KCacheGrind. Complete commands to install, configure and run a sample debug session are all included. Sample outputs from the KCacheGrind software are there too: code structure, execution times.

In this new post to his blog Vito takes "a quick look" at the newly released Tokyo Tyrant extension for PHP (an interface to the Tokyo Cabinet key/value store).

Here's a quick, rough look at the speed of the Tokyo Tyrant extension for PHP released by Mikko 2 days ago. I am using it as an on-memory hash. Profiling done with xdebug on PHP 5.3.0.

He includes two shots of the output from a sample run with PHP 5.3.0 - one showing a simple execution of a get and put for a set of values and the other comparing the simplicity of that to a more complex request structure for this implementation of a Tyrant interface.

Rob Allen has a new post with some tips for those using the Zend Server Community Edition on OS X. While the Server installs a lot of the necessary software, there's still a few changes in the configuration and extra software he wanted - PHPUnit and Xdebug.

I've installed Zend Server CE on my Mac to see where it's got to and it's looking quite usable. The installation puts everything into the usr/local/zend directory which is fairly well laid out so that you can find what you are looking for. There's also a a nice admin system at http://localhost:10081 which allows you to restart PHP, view phpinfo(), configure extensions and php.ini. There's also a phpMyAdmin to help administer the bundled MySQL server. For Mac, this is now one of the better one stop shops for easy PHP & MySQL installation.

He shows how to set up pathing to include the Zend Server binary directories in your shell's paths, how to change the port over to 80 from the default 10088 and how to install PHPUnit and Xdebug.

For most developers, working with XDebug is a simple matter of setting up the extension and getting to work. For larger teams, though, its not quite that easy. The way that XDebug is set up by default, it's no quite conducive to multiuser situations. Derick Rethans is here to help in his latest blog post, though. He describes a method (using a DBGp proxy) to handle splitting things between multiple developers.

As author of Xdebug, people ask me often the question how to handle the case in teams when there is one development server and multiple developers working on the same project on that server. [...] Now, in order to solve the above mentioned issue, you will need to run a DBGp proxy. DBGp is the protocol, designed by ActiveState and myself to facilitate communication between an IDE and PHP+Xdebug.

He walks you through the setup process - how to point XDebug to the correct location and how to configure the proxy to handle the multiple incoming requests and route the debug information back to the correct client.

Chris Jones has pointed out that the Google Summer of Code Projects for 2009 has been finalized and several PHP projects are on the list.

There's seven projects with a wide range of topics - here's the list:

• run-tests.php improvements
• Add decision and path coverage to Xdebug's code coverage instrumentation
• Bug Tracker Improvements
• PhD Improvements (Plugin System)
• Abstract Extension API and Dependency Interface
• Benchmark creation
• PhD O.E. - Online editor for the PHP Manual

You can find out more about the Google Summer of Code here.