In a recent post to his site James Cowie sings the praises of Xdebug for debugging and says that "var_dump must die" as a method for debugging in your application development flow.

How many times have you been working in Magento or any other php application and hit an error, exception or something not quite right? For me a lot. I’ve been that developer that debugs by fire and throws echo var_dumps and dies around like a western gunslinger. It’s easy, provides quick feedback cycles but lets be honest its lazy, in efficient, rarely provides all of the data you need to solve the problem on the first try and its not something you want to boast about by the coffee machine.

[...] So whats the “better” way of debugging a application? Well welcome Xdebug + PHPStorm. Imagine inside of the IDE we can set a breakpoint, a fancy die and reload our web page. Magically the IDE has stopped execution and we can see the state of the application at that exact path. We can see the variables and we can step through the code and see exactly what class and method is called next and so on and so forth.

While his instructions are specific to PHPStorm, most major IDEs will have a similar setup process with their own tweaks. In his case, though, he has one more layer of complexity - the PHP is executing inside a Docker container. He walks you through the process he followed to get the flow from container to local IDE set up. He wraps up the post with an example of debugging a script and what the results look like inside of PHPStorm (including a screencast).

The PHP Roundtable podcast, with host and PHP community member Sammy Kaye Powers, has posted their latest episode with a look at why "Debugging is more than var_dump()". In this episode Sammy is joined by Derick Rethans (of Xdebug fame), Colin O'Dell and Gary Hockin.

Believe it or not, there's a lot more to debugging your PHP code than var_dump()'ing all the things. We discuss how to use debugging tools to help us comprehensively debug our codebase.

You can watch the playback of the live recording of the episode either using the in-page video player or directly on YouTube. If you enjoy the episode be sure to subscribe to their feed and follow them on Twitter to get information about new episodes as they're released and when future live recordings are happening.

The 7PHP.com site has posted another in its series of spotlights on people and happenings in the PHP community. In this latest edition he talks with Cal Evans about the latest Day Camp 4 Developers evening happening Friday, September 18th: "Debugging Beyond var_dump()".

Day Camp 4 Developers is a virtual ‘mini’ PHP conference. Meaning you can watch in realtime 5 awesome speakers, talking about some cool quality stuffs, while you are comfortably seated on your sofa with your snacks and beverages. [...] It’s a new week on our PHP Calendar, specially in our Virtual PHP calendar – it’s THE week for DC4D which will be held on this upcoming Friday 18th Sept 2015 – see it all here, click! One very important thing to know, DC4D is heartily brought forward by our PHP Icon – the one and only Mr Cal Evans, together with his wife, The Lovely & Talented Kathy.

Cal answers questions about the event including:

• How it all started
• How he finds the speakers for the theme for each event
• Some of the things he's learned from putting on the event

The interview also includes a bonus Q&A with one of the speakers, Joshua Thijssen. They talk about Joshua's motivation behind the talk, one things that people will learn from it and what he sees as the benefit of a live presentation vs recorded.

The Day Camp 4 Developers online "conference" has officially announced their latest event, "Debugging Beyond var_dump()", happening Friday September 18th from 9am through 3pm (CST). This time around they're putting it on with the help of the fine folks at php[architect] too.

This latest edition of the excellent event features several well known speakers talking about debugging tips and sharing tools that can make you a more effective developer:

• "PHP Profiling, an Introduction" (Fabien Potencier)
• "Debugging: Past, Present and Future" (Derick Rethans)
• "Characterization Testing for Legacy Applications" (Paul M. Jones)
• "Modern Tools for API Debugging and Testing" (Neil Mansilla)
• "Don't Reboot, Debug!" (Joshua Thijssen)

Much like it's siblings, the Day Camp 4 Developers event is completely virtual and is held via a webcast. Tickets will soon be sale and, compared to the usual cost of a conference ticket, are quite cheap. There's even group tickets available if you'd like to hold a "watch party" in your office.

Check out the Day Camp 4 Developers site for more information or to pick up your tickets!

Derick Rethans has a new post to his site starting a series of posts about the new features of Xdebug 2.3. In this new post he talks about an improvement that's been made to the output provided by var_dump with more information than before.

One of the new features relates to one of the first things that I added in the original Xdebug: making the var_dump() output "pretty". Xdebug replaces PHP's standard var_dump() function with its own version, as long as the xdebug.overload_var_dump setting is not set to 0. [...] Xdebug 2.3 enhances the overloading of var_dump() with the inclusion of the file name and line number where var_dump() is called at. This has been a long standing feature request.

He provides a few sample screenshots comparing the old and new output formats and mentions another handy setting, xdebug.file_link_format, that makes the resulting filename a link in a browser and lets you customize the format.

As a part of his "Advent Contribution" series Derick Rethans has posted about an update to XDebug that fixes a bug reported around hidden properties.

This first contribution is for bug #987: "Hidden property names not shown". In PHP it is possible to convert an array to an object. [...] Xdebug's standard HTML var_dump() as well as the CLI, the coloured CLI and the debugger interface DBGp all suffered from the same issues that numerical properties were not showing in output.

With the committed fix the output of the var_dump now shows these special property names with curly braces around them and makes them available via the property_get method. If you're interested in the actual commit, you can check it out here.

Sameer Borate has posted about using Kint, a "more powerful debugger" that lets you output more data than just the usual var_dump or print_r provides and in a much more readable format.

My standard debugging tool when using PHP is xdebug. Pairing xdebug with Komodo gives me a very productive environment for building PHP applications. However, testing an application code on a hosted server can be many times frustrating as one has only the print_r and var_dump functions at our disposal. What I need is a library that I can easily install on the server and start using. Although there are a few debugging libraries around, one of my favorites is Kint.

He walks you through the installation of the tool and provides an example of the most basic usage (and output) from a call to the tool's "dump" function. He also gets into some of the additional features the library provides including intelligent formatting, debug tracing and limited theme configuration.

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.

Phil Sturgeon has a quick new post with a code snippet that could make your debugging life a bit simpler - a "dump" function that can give you a bit more information about your error than a standard var_dump.

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.

Matthew Turland came across an interesting bug when working with the Cares Document Checker he's developing related to linting (running a syntax check) on a given PHP file.

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.