Xdebug is a PHP extension which helps you to understand, debug and profile PHP. It can help you to find bottlenecks or give you an quick overview what happens in code you aren't familiar with, yet.

The post gives a brief overview of the installation of the extension (building a shared module) and shows how to get started with profiling an application. He talks about the cachegrind tool you can use to parse the results and the kcachegrind app that will make the results a bit more visual.

As a bonus, he also throws in a bit about function tracing - picking out each small bit of functionality in the code (the function/methods) and gathering stats for each.

The Web services client class, WSClient has two methods for this, getLastRequest() and getLastResponse(). After calling the request() method of the client instance, you can call any of those methods to gain access to the messages.

Simple example code is included showing how to grab that information from the client object. If you're looking for a way to get the WSF/PHP functionality installed on your system, check out this step-by-step tutorial on using the PECL tool to create and install the packages to your PHP setup.

Welcome to the second installment of our five-part series of articles on xdebug, the PHP developer's swiss army knife extension. The installation of xdebug and its basic features were covered last week. This week, we will explore the tracing feature of xdebug.

He details what tracing is and how it's helpful (no more repetitive var_dumps!) in finding issues in your code. He shows how to set up a trace log, add the code to your application to pass debugging information off to the log and how to add additional information to the log to make narrowing down the error even easier.

This article is the first installment of a five-part series of articles covering xdebug, a free and open source swiss army knife tool for PHP developers. xdebug is a PHP extension created by Derick Rethans, one of the PHP core developers. This week, we will show you how to install xdebug and introduce you to some of the basic features. In the subsequent parts of this article series, we will have a closer look at one of xdebug's main features, namely tracing, profiling, debugging, and code coverage.

In this first installment, he looks at installing the software (both on a unix-based system and on a Windows box) and how to turn it on to work with your web server. He also mentions some of the error output options including the "new and improved" var_dump call and the stack trace method to help you locate exactly where in the code the error's hidden.

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.

I've always been annoyed by the way how Xdebug's stack traces looked liked. So I spend some time on making them look better. I will show the differences according to the following script.

The simple script takes the output and adds a bit of formatting, stripping down the information to make it a bit more clear. Check out the before and after shots to see the difference.

Sometimes it's not very easy to check if a vulnerability occured where Morcilla told you it occured. In order to pinpoint this issue, it is neccessary that you get a deeper look to the callstack of all the functions that were involved calling the SQL abstraction layer.

They include a screenshot of how the functionality will (in the upcoming version) work in the case of a MySQL SQL injection problem.