Recently, Symfony went from Zend-like bloat and rigidity to extreme decoupling and modularity. With the new Developer Experience initiative, Symfony has done a Laravel-style 180° and dove right into making its components more end-user friendly, its docs more complete, and its AppBundles unbundled, simplifying entry and further development almost exponentially. Considering user friendliness, it’s a long way from “best pals friendly” but it’s definitely no longer hostile. One factor that contributes to this factor a lot is their continuous pushing out of new components that are incredibly useful outside of Symfony’s context. One such component is the new VarDumper.
SYMFONY LOGO
Why?
You’re developing a feature. You either don’t feel like writing tests, or what you’re developing needs some variable testing in the middle of a function – something you can’t quite cover with a test. Inevitably, you resort to something like die(var_dump($var));. Even if you’ve abstracted it into a shorthand method like vddd($var), it’s still clumsy and unreadable, and tends to leave debugging snippets around your code, either as comments or, even worse, as code that can actually be triggered.
There’s little choice in the matter – sometimes we simply need our vddds. And sure, if you’re an Xdebug user, you’re probably used to a slightly better looking output than the raw PHP prints. Still, few good solutions existed that beautified this output for us enough to make it worth installing a dev dependency. Until VarDumper.
You should encourage people to use proper tools for this kind of work, like xdebug.
From mine experience south debugging code often ends up on the production.
Using debugger one could inspect every variable (see value and type), check execution path or find places where some code is being invoked (breakpoints + call stack → very useful for reverse-engineering)
Performance hits and installation of extensions (shared hosting friendly, I guess?)
Also, in small throwaway projects, sometimes setting up Xdebug properly isn’t worth the time and effort. If I’m testing a tutorial demo and checking for bugs, I’ll have a throwaway vagrant box defined which I can scratch after I’m done. The entire ordeal probably wouldn’t take more than 20 minutes, which is far too short to set up Xdebug anyway.
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.
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?
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.
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.
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
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).
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.
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.
