Chris Jones has a new post showing how you can use Emacs and Xdebug for debugging with the help of the geben plugin.

When you want to test a PHP code snippet quickly, it's handy to do it within your day-to-day environment. For me, this environment is Emacs. The geben package for Emacs provides an interface to the DBGp protocol, such as used by Derick Rethans's standard Xdebug extension for PHP. With the combination of geben and Xdebug, I can quickly and efficiently step through execution of local files, examining code flow and data values.

He includes a ten step process (step 11 is basically "use it") that walks you through the installation of the full stack - PHP, Xdebug and geben - and the configuration changes you'll need to make to get them all working together. Some basic usage instructions are included, but if you want more details on using geben, check out the project's site.

On 7PHP.com today Khayrattee Wasseem has posted his latest interview with a member of the PHP community - this time it's Derick Rethans "The Father Of The PHP Swiss-Army Knife aka Xdebug".

In this edition I talked with Derick Rethans the Father Of The PHP developer's Swiss-Army Knife aka Xdebug. Derick is an expert when it comes to the PHP Internals; no wonder he is viewed as a vibrant and "man of action" within The PHP Community. As a PHP Core Contributor, he has been at the crux of many PHP extensions and variations; the mcrypt, date and input-filter extensions, bug fixes, additions and even leading the QA team.

Derick answers questions about how he got involved with PHP and how he thinks it compares from then to now. He also talks some about what tools he uses for his development and more details behind Xdebug's origins and PHP extensions in general.

Joshua Thijssen has a recent post for all the PHPStorm users out there (or maybe investigating a new IDE) and are looking for a way to debug your PHP apps easily with XDebug. Well, he's come up with a step-by-step guide to help you get it all set up and working, complete with screenshots. He helps you debug command-line applications, but the setup will work for your web apps too.

Even in these days, with full-featured PHP IDEs around, I still see PHP developers using var_dump() and die() to debug their code. Not only is this a very bad way of "debugging", it has other dangers as well [...]. We've probably all been there,.. But we don't have to. Debugging your code properly through an IDE is quite easy, but one of the major problems is debugging CLI code. Since many frameworks like Zend, Symfony and micro-frameworks like Cilex can be used to create command-line apps, cronjobs and even "deamons", so how do we easily debug this kind of code?

He starts with the setup of a development instance (he recommends a clone-able virtual machine environment) and shows how o configure both XDebug and PHPStorm to work together happily. He shows what configuration options and steps you'll need to take to be able to debug the CLI apps too, including a command-line option to specify the IP to report the debugging into back into.

In a previous post Pablo Viquez talked about integrating JMeter and Zend Debugger for testing your PHP applications. In this new post he goes one more step in and talks about integrating Eclipse, JMeter and using XDebug this time for the debugging.

In a previous post I wrote about doing step by step debugging using Zend Debugger and Zend Studio making the calls from JMeter, however not everyone has Zend Server or Zend Studio installed, and since XDebug is an awesome project I though that will be awesome to do the same using XDebug. [...] As explained previously, using the browser for API debugging can be pretty hard or nearly impossible unless you build some sort of UI, which normally I do not have time to do, so JMeter is perfect for the job!

He includes the configuration changes that'll need to be made to Apache and how to set up and configure the new project in Eclipse. He also includes the setup of the jMeter plan (using his example) and executing it to execute the script/get the debugging information.

On PHPMaster.com today there's a new tutorial showing you how to effectively debug your applications with Xdebug, a handy tool that provides more detail around your errors just by installing it.

Xdebug is a free and open source project by Derick Rethans and is probably one of the most useful PHP extensions. It provides more than just basic debugging support, but also stack traces, profiling, code coverage, and so on. In this article you'll see how to install and configure Xdebug, how to debug your PHP application from Netbeans, and how to read a profiling report in KCachegrind.

He walks you through the installation process (installing it from a package, not compiling) and how to enable it in your "php.ini" configuration file. He also shows how to hook it into the debugger on your IDE (in this case Netbeans) to receive debug messages and be able to step through the code to easily locate the issues. Also included is some basic information about profiling your application and viewing the resulting data in something like Kcachegrind or Webgrind

On the Silver Lining blog (a MSDN Windows Azure related site), there's a recent post showing how you can enable XDebug on your Azure instance to help with debugging your application.

In this post, I'll cover how to run XDebug (including the profiler) in Windows Azure Web Sites. Enabling XDebug in Windows Azure Web Sites is as simple as enabling an extension. However, enabling an extension for the built-in PHP runtime is slightly different than doing so for a custom PHP runtime. I'll cover both scenarios here.

The post is broken up into two sections - one if you're just using the built-in PHP runtime that's already in the instance and another if you're using a custom one of your own. Changes to the configuration files and some screenshots of where to make the updates are included.

Danne Lundqvist has a new post today showing you how to install and use XDebug with MAMP, the popular all-in-one LAMP package for OS X.

MAMP is a full local server environment including Apache, PHP and MySQL in one package. Anyone feeling at home in *nix systems should feel at home using both OS X and MAMP. [...] As I have helped a few collegues setup Xdebug in MAMP I have discovered that a lot of developers don't do this as they don't know how simple it is. Even seasoned PHP developers use the old echo/die debugging techniques.

He includes all the changes you'll need to make to configuration files and makes a simple script you can use to test out that things are working. As his IDE of choice is PHPStorm, he shows how to set up the remote debugging to work and reply back as the script is executed.

Miro Svrtan has a quick tip for those using the Uploadify plugin in their application's file uploads - how to enable XDebug debugging on each upload request.

If you ever decided to use Uploadify jQuery plug-in you might have noticed problems with debugging remote PHP code that this plugin relies on. [...] Unfortunately setting this up will not work with Uploadify Flash version since calls to remote server side is not done inside browser but inside flash plugin. [...] Few months ago I found my self blindly debugging it again and remembered that I read somewhere that xdebug parameters can be sent via GET/POST too.

He takes advantage of this fact and appends the "XDEBUG_SESSION_START" and "XDEBUG_SESSION" values in the "scriptData" handler for the Uploadify call. The XDebug session is then started when the script executes and your IDE will receive the results.

Rob Allen has posted some notes to his site helping you get PHP set up on OSX Lion (10.8) successfully.

With OS X 10.8, Apple continues to ship PHP 5.3 with Xdebug, PEAR, GD and PDO_MYSQL. This is how to set it up from a clean install of 10.8.

He's broken it up into a few sections including the MySQL setup, Apache configuration , updating the main php.ini and setting up PHPUnit ("and friends") for your testing. He also includes setup instructions for the mcrypt and the PECL OAuth extensions.

In this new post on DZone.com, Giorgio Sironi suggests that "all debugging and no testing" in your development practices can be more difficult in the long run.

By now you have already understood that I would always proposed automated end-to-end and unit tests as a way to substitute much of debugging. End-to-end tests can serve only to discover that a bug exists, while a unit test's job is instead to tell you exactly where the problem is.

He advocates testing because it fits two needs - it's repeatable (a consistent, "third party" structure) and it allows you to find the pieces of code causing the issue more quickly rather than having to guess where the problem is an insert checks. He doesn't suggest completely getting rid of things like Xdebug, though. They have their place and he even suggests some configuration changes that can help make it even more effective.