When trying to work out what the hell is going wrong in your PHP application the first thing most of us start doing is madly start var_dump()'ing everything possible to work out where the problem is. var_dump() is fine, but by default it comes out in one line. So then we need to echo <pre> tags. Then we can't always see whats going on, especially if the background is black and bla bla bla so it goes on.

He mentions an alternative like XDebug, but that also requires access to install it on the server. His alternative, the "dump" function, catches the error, pulls out a backtrace of the path your script took to get there and echoes it out with the line number of the error and filename.

While doing a lint check on a code block, a parse error was occurring on a line that contained a comment in the original source file. [...] Presumably what was happening was, even though the var_dump() call showed that actual newlines were being interpreted correctly, the r was also being interpreted rather than taken literally. This caused the comma following it to generate the error I was receiving.

An alternative to the method he was using, shell_exec, is proc_open, a function that opens a resource to handle a command execution and allows for more than just the "point and shoot" execution that things like shell_exec, or system.

As you may know, "var_dump()" is a PHP native function, but the X-debug library provides an enhanced version of it that's capable of retrieving much more information about a supplied variable. These capabilities greatly extend its usefulness in debugging.

This enhanced version of var_dump displays not only the usual variable information (types, value, etc) but also allows for more advanced output like the object definition, including properties, in their example.

PHP has a large number of tools for fixing bugs and resolving underlying issues. But many people don't know what they are, and some of them are extensions requiring installation in order to work. In this series, we'll explore some features for debugging PHP scripts, from the most basic to more advanced.

He looks at three of the most basic ones (and ones that most developers I know out there use every day) - var_dump, print_r and var_export. Examples of each in use are included...

To put it simply, Krumo is a replacement for print_r() and var_dump(). By definition Krumo is a debugging tool (now for PHP5 only), which displays structured information about any PHP variable [...] it does the same job, but it presents the information beautified using CSS and DHTML.

It also supports output of other data in a "pretty format" like backtraces, included files and a listing of all constants. You can check out a demo of it in action here.

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.

Being a whimsical sort, I decided that actually implementing his request would be more fun than simply pish-poshing it. I'm not suggesting this be part of PHP6 (I still don't personally think it's a good idea), but it's a fun exercise and good for a conversation starter...

There's several things she can now do with the special characters including dumping out the results of divisions, comparisons and fractions natively.

As of PHP 5.2.1, json_decode() no longer follows the published standards for JSON-encoded texts. Why not? For no reason other than the convenience of those ignorant of JSON standards.

His complaint stems from the results of a vat_dump statement - prior to this version it would give a NULL, but now it returns a "bool(true)" value back, resulting in some breakage of previous scripts. He spends the rest of the post explaining his voyage through the JSON world and how things are supposed to behave. He also digs a little deeper into the var_dump issue and why he thinks it's such a bad thing.