No More var_dump - Introducing Symfony VarDumper!

That’s true, especially performance hit. I usually turn on xdebug extension only for debugging sessions.

Does any IDE has support for build-in php 5.6 debugger ?

Yes, PhpStorm.

So… it makes a pretty var_dump. Doesnt remove any code (in fact, adds a line).

If your dump is several layers deep, you’ve got to click around and open all the layers to find what you’re looking for. Assuming you actually know what you’re looking for ahead of time.

Or… i could just View Source a var_dump.

Interesting package. I’ve added it to a laravel app, but a dump() of a eloquent collection with 150 over items only has the 1st five expandable. The rest were truncated with ....
Any idea how to configure VarDumper to show all details instead of truncating them?

Hmm, not right now. Let us know if you find an easy way.

Maybe something along these settings might help. You might have to find a way to feed it the configuration, though, since this applies only to when it’s used within the DebugBundle.

Disclaimer: author of Kint here.

I’d just like to encourage those who have not heard of it, check Kint out:

https://github.com/raveren/kint/tree/1.0.0-wip

It’s been in the works for years, has tons of useful features like keyboard navigation, plain text alternative, trace output and so on, and most importantly - it’s effortless to install and use. Composer support is there, but highly optional - and Kint even supports PHP5.2 when you’re stuck with terrible old projects. Needless to say, every later major version is supported and provides more functionality.

Looks good, thanks for chiming in! A “battle of the vardumpers” article might not be a bad idea :slight_smile:

As the main author of the VarDumper component, thank you for this article!
If you really plan to write a “battle of the vardumpers”, let me know :smile:
One main example with all other dumpers is how (hard) references are dumped: with VarDumper, you can inspect/read them. With others, they are at best replaced by a recursion warning.

VarDumper is focused on extracting the highest possible accuracy about any PHP variable. It never fails with highly complex structures nor in any layer of your PHP app (try e.g. dumping in a PHP output buffering handler).

VarDumper is also highly modular so you could build more than one dumper (I would even encourage LadyBug/Kint to build theirs on the state extraction mechanism of VarDumper).

Debugging can’t be done efficiently without robust tools. The xdebug vs dumpers discussion will never end imho because both serve different use cases / group of users (I personally use the two of them).

For Silex integration, you should try https://github.com/jeromemacias/Silex-Debug
And for the ellipsis that show up too fast, I’ve raised the default 250 items limit to 2500, that should help.

Thanks for chiming in! I actually am planning to do a battle of the VarDumpers, for real :slight_smile: Just need a good scenario that tests them all. Ideas welcome :slight_smile:

Regardless of the debugger you choose, loading the debug library with the php auto prepend file directive is highly useful. I know of no community frameworks that make use of that directive and in ten years I’ve only seen one custom program use it.

This approach insures you won’t accidentally push debug code live since the two are segregated.

+1 for Kint, it’s awesome, thank you for taking the time to create it Raveren

Guys, i think this tool and this article mainly wrote for Symfony2 developers as using the native var_dump() against Symfony2 Objects is horrible, so they tried to fix this and address it to us in a political way.

anyways i really helps when developing using Symfony2

Topic is quite old but I would like to clarify. PhpStorm - as any other PHP IDE - does not support phpdbg yet. But development is ongoing https://youtrack.jetbrains.com/issue/WI-21414.

@swader don’t forget Tracy for the VarDumpers battle :wink:

Thanks, I’ll keep it in mind!

I ran into this thing and it got me away from using my handmade suite - that’s a feat right there. I’m incorporating it into a patch I’m writing for Drupal 8 to improve how the stacks are dumped on the error event when the system is configured into dbug mode. It’d definitely a help there since drupal’s objects are huge and massively recursed.

1 Like

One should always pick a debugging solution that would work without changing the codebase back and forth. Any kind of var_dump should never be available on production. Any method used should always include a production check and disablee the output eg. if (PRODUCTION) dont dump.

Last time I checked it was fully possible run any one of a number of PHP’s debug statements on a production box if you’re foolish enought to do so. How is this any different?

Ironically I had this discussion with my boss eariler today. I give you the same challenge as I gave him - how is this any more destructive or harmful than leaving a print_r(); exit; series in the code?

Answer, it isn’t.

Keeping test code separate from production code is an issue beyond the scope of what this tool addresses.

using print_R() and exit is just as harmful as I have cleaned up the code on production when those debug statements got released on production.

I dont say you shouln’t use them but always do something like this instead:

if (!empty($_GET['we_are_debugging'])) {
   print_R('data');die()
}

with that simple check you can debug on local and production still continues to work.

That being said, your unit tests should catch it before that though

EDIT
This post has been reformatted by enclosing the code block in 3 backticks
```
on their own lines.