Symfony has even more debugging tools. The easiest way to get all of them is to find your terminal and run:

composer require debug --dev

Find your browser, surf back to and search for "debug". Ah, so the debug alias will actually install a package called symfony/debug-pack. So... what's a pack?

Click to look at the package details, and then go to its GitHub repository.

Whoa! It's just a single file: composer.json! Inside, it requires six other libraries!

Sometimes, you're going to want to install several packages at once related to one feature. To make that easy, Symfony has a number of "packs", and their whole purpose is give you one easy package that actually installs several other libraries.

In this case, composer require debug will install Monolog - a logging library, phpunit-bridge - for testing, and even the profiler-pack that we already installed earlier.

If you go back to the terminal... yep! It downloaded all those libraries and configured a few recipes.

And... check this out! Refresh! Hey! Our Twig dump() got prettier! The debug-pack integrated everything together even better.

Unpacking the Pack!

Go back to your Twig template and remove that dump. Then, open composer.json. We just installed two packs: the debug-pack and the profiler-pack:

67 lines composer.json
... lines 2 - 15
"require-dev": {
... line 17
"symfony/debug-pack": "^1.0",
... line 19
"symfony/profiler-pack": "^1.0"
... lines 22 - 65

And we now know that the debug-pack is actually a collection of about 6 libraries.

But, packs have a disadvantage... a "dark side". What if you wanted to control the version of just one of these libraries? Or what if you wanted most of these libraries, but you didn't want, for example, the phpunit-bridge. Well... right now, there's no way to do that: all we have is this one debug-pack line.

Don't worry brave space traveler! Just... unpack the pack! Yep, at your terminal, run:

composer unpack debug

The unpack command comes from Symfony flex. And... interesting! All it says is "removing symfony/debug-pack". But if you look at your composer.json:

71 lines composer.json
... lines 2 - 15
"require-dev": {
"easycorp/easy-log-handler": "^1.0.2",
... line 18
"symfony/debug-bundle": "^3.3|^4.0",
... line 20
"symfony/monolog-bundle": "^3.0",
"symfony/phpunit-bridge": "^3.3|^4.0",
"symfony/profiler-pack": "^1.0",
"symfony/var-dumper": "^3.3|^4.0"
... lines 26 - 69

Ah! It did remove symfony/debug-pack, but it replaced it with the 6 libraries from that pack! We can now control the versions or even remove individual libraries if we don't want them.

That is the power of packs!

Leave a comment!

  • 2018-04-16 Victor Bocharsky

    Hey Petru,

    Yes, if you interrupt executing with "die()" or dump() in Twig files - it prints the output immediately. But by design, if you dump() something in PHP files and do not interrupt with "die()" - it is not showed on the page - instead the output is putted into Symfony web debug toolbar, see a small target icon. It's on purpose to hide the debug output from the main content to prevent breaking the page.


  • 2018-04-15 Petru Lebada

    Hi Ryan,

    I have a problem with dump() in the show method.It doesn't show anything.... prior to an answer u gave on the previous chapter about installing debug pack this chapter i waited to test it out,yet it didnt solve the problem.If i {{ dump() }} in .twig template, everything's ok, but in the controller it just not show it if i dont use die; right after ... Any ideas on this?

  • 2018-02-13 Ramsey Jiang


    Thank you so much. I find that dump in the Symfony Web Debug Toolbar below.

  • 2018-02-13 Victor Bocharsky

    Hey Ramsey,

    Please, make sure you have installed Var Dumper component with:

    composer info symfony/var-dumper

    IIRC, that this works in dev/test environments only. If you're in prod - it probably won't work. And keep in mind that in PHP files dump() works in a bit different way than in Twig templates: if you dump something in PHP file - you won't see the output on the page, but you can see it in the Symfony Web Debug Toolbar below.

    P.S. If your output of var_dump() is just black/white, i.e. not colorful and nice - then you need to install and enable Xdebug PHP extension which makes var_dump() output much nicer.


  • 2018-02-12 Ramsey Jiang

    Hey weaverryan

    Your first part is 100% correct. Thanks what I have done before this chapter.

    The second part, in my PHP, var_dump works, but in symfony4, dump() is not work. I don't why. That's why I ask at here hope someone can help me to fix it. I did cache clear, but the problem is still there.

    You know, in my controller, dump() it's not work, it won't output anything. Only var_dump() works. but the output is uglier not prettier. Before this chapter, dump() in my controller works and pretty. My controller code is following:

    * @Route("/article/{slug}")
    public function testArticle ($slug)
    $comments = [
    'I ate a normal rock once. It did NOT taste like bacon!',
    'Woohoo! I\'m going on an all-asteroid diet!',
    'I like bacon too! Buy some from my site!',

    dump($comments, $this);//dump at here is not work, it cannot do anything. Only var_dump works.

    return $this->render('article/show.html.twig', [
    'title' => $slug,
    'comments' => $comments

  • 2018-02-12 weaverryan

    Hey Ramsey Jiang!

    Hmm. This should *not* be the situation. You're 100% correct that, before this chapter, the dump() function in Twig was using var_dump. That is Twig's default functionality. But when you install the debug-pack, Symfony replaces this with the VarDumper component implementation (that is responsible for the pretty, black background).

    But in PHP, the dump function is provided by the VarDumper component. If that component is not present, then the dump() function should not exist. And, of course, if it IS present, the VarDumper always prints "pretty". I can't think of how the dump() function would ever produce the uglier, var_dump version of the code :/. Just in case, try clearing your cache:

    php bin/console cache:clear

    If that doesn't work, could you post your controller code? I know it's simple - but I'm really not sure what the issue could be :).


  • 2018-02-10 Ramsey Jiang

    Hey Diego Aguiar
    You know, at the previous chapter, I could use dump in my controller. I could view a background color is black of that dump. In the twig, I also could use dump, but the dump is as the php var_dump.

    After I viewed this chapter, the dump in my controller as the php var_dump. the dump in my twig, it has a black background color.

    Now do you make sence what I mean in my question?

  • 2018-02-09 Diego Aguiar

    Hey Ramsey Jiang

    What you mean with that you made controller's dump uglier?
    When you dump something in a controller, don't you see a new input at your profiler's bar?


  • 2018-02-09 Ramsey Jiang

    In previous chapter, I made prettier controller dump but ugly twig dump.
    After I view this chapter, I made a prettier twig dump but ugly controller dump.

    Who can help me to make prettier both controller dump and twig dump? My composer dev is following:

    "require-dev": {
    "easycorp/easy-log-handler": "^1.0.2",
    "symfony/debug-bundle": "^3.3|^4.0",
    "symfony/dotenv": "^4.0",
    "symfony/monolog-bundle": "^3.0",
    "symfony/phpunit-bridge": "^3.3|^4.0",
    "symfony/profiler-pack": "^1.0",
    "symfony/var-dumper": "^3.3|^4.0"

  • 2018-01-24 Victor Bocharsky

    Hey Christian,

    Yeah, no problem! The main thing is that it works ;)


  • 2018-01-23 Christian Lacroix

    Hi Victor,
    I am sorry but I did not remember from which version of composer I updated.
    I am on Mac os X High Sierra. I did sudo composer self-update. (I have put composer globally on /usr/local/bin/composer)
    Since I wrote this question, I retried a lot of time and it works every time.
    I am afraid it will remain a mystery.
    Thanks for your reply.

    Best regards


  • 2018-01-23 Victor Bocharsky

    Hey Christian,

    Hm, what OS are you on? I think it's a feature in Composer upgrade process. How did you upgrade to the latest version? Maybe during upgrade some symlinks were changed by Composer, but you didn't see actual changes in the same terminal tab. It's difficult to be sure without extra debugging which is pointless since now it works for you. Also, it's interesting to see the real version of composer when you saw that error, I bet you had not the latest one.

    Anyway, I'm glad it works now for you.


  • 2018-01-22 Christian Lacroix

    I tried again after a system restart and now it works.
    Don't know why, but it's cool

  • 2018-01-20 Christian Lacroix

    Hi Ryan,
    I installed composer 1.6.2 and created project from symfony/skeleton.
    Then I added debug pack.
    When typing "composer unpack debug" I get the following error:

    Command "unpack" is not defined.

    I tried with composer 1.5.6 and I get the same error.
    Do you have any idea ?

  • 2018-01-17 weaverryan

    It all makes sense then! So, you definitely found a bug in Symfony - nice work! It's quite difficult to do :). When you have time to change the order of the bundles, it will fix the problem. But in the future (when the bug fix is merged), it won't make a difference thanks to your report!


  • 2018-01-17 Thomas Talbot

    I can't change the order of these bundles for now.
    I'll do it tomorrow. ;)

    Hmm, actually, I did not exactly do what you did after symfony/skeleton... :-s
    Anyway, thanks you very much for your help. :)

    bundles.php :
    return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineCacheBundle\DoctrineCacheBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
    Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle::class => ['all' => true],
    Symfony\Bundle\DebugBundle\DebugBundle::class => ['dev' => true, 'test' => true],
    Symfony\Bundle\MonologBundle\MonologBundle::class => ['all' => true],
    Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true],
    Symfony\Bundle\TwigBundle\TwigBundle::class => ['all' => true],
    Symfony\Bundle\SecurityBundle\SecurityBundle::class => ['all' => true],
    Nelmio\Alice\Bridge\Symfony\NelmioAliceBundle::class => ['dev' => true, 'test' => true],
    Fidry\AliceDataFixtures\Bridge\Symfony\FidryAliceDataFixturesBundle::class => ['dev' => true, 'test' => true],
    Hautelook\AliceBundle\HautelookAliceBundle::class => ['dev' => true, 'test' => true],
    Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle::class => ['all' => true],
    Omines\DataTablesBundle\DataTablesBundle::class => ['all' => true],
    Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle::class => ['all' => true],

  • 2018-01-17 weaverryan

    ... and here's the pull request to fix the bug :).

    What's interesting is that you should NOT have hit this bug if you installed the packages in the same order that I did. Did you install in a different order? That would explain it :).


  • 2018-01-17 weaverryan

    Hey Thomas Talbot!

    Indeed... I believe you are correct that the core dump() function is winning! And I think I've found the problem. Would you mind posting your config/bundles.php file here? I believe if you change the order of TwigBundle and DebugBundle in this file, it will fix it :). I'm going to open an issue or PR on Symfony's repo about this!


  • 2018-01-17 Thomas Talbot

    Thanks for the explanation. It was about what I thought. :)
    Perhaps the twig-bridge's one is overriden by twig/twig ? weird...

    Here the output of bin/console debug:container --show-private twig.extension.dump :

    Information for Service "twig.extension.dump"

    ---------------- ---------------------------------------------
    Option Value
    ---------------- ---------------------------------------------
    Service ID twig.extension.dump
    Class Symfony\Bridge\Twig\Extension\DumpExtension
    Tags twig.extension
    Public no
    Synthetic no
    Lazy no
    Shared yes
    Abstract no
    Autowired no
    Autoconfigured no
    ---------------- ---------------------------------------------

  • 2018-01-17 weaverryan

    Hey Thomas Talbot!

    Ah, so it gets more interesting :). Well, in case it helps, let me show you how it works behind the scenes. When the DebugBundle is activated, it registers this service: This activates a dump() function ( that should OVERRIDE the one from core Twig:

    Phew! So, you should *not* see the twig_var_dump in your compiled HTML. A few things to check:

    1) Clear your cache, just in case
    2) Try bin/console debug:container --show-private twig.extension.dump - does it show that this service exists?


  • 2018-01-17 Thomas Talbot

    My bad, I'v forgotten to say that I installed it via debug-pack.

    So, I have this problem with symfony/debug-bundle installed. :/

  • 2018-01-17 weaverryan

    Hey Thomas!

    Yes, I know this! Actually, you did a very similar thing to what I did in the previous chapter. When I installed the profiler, that installed the var-dumper, which gave us the pretty dump() function in PHP. But in Twig, my dump() was ALSO "ugly" until THIS chapter, when I ran composer require debug. I believe the missing piece is Symfony's DebugBundle (which comes with the debug "pack"): this adds the integration between TwigBundle and VarDumper. So if you install that, or just install "debug" to get the debug pack, it should get pretty in Twig :).


  • 2018-01-17 Thomas Talbot

    Hi Ryan,

    Thanks a lot for this course. :)

    When you added symfony/var-dumper, your `{{ dump() }}` got prettier. :)
    I have the symfony/var-dumper and symfony/twig-bundle... but it outputs with xdebug not VarDumper component.

    In the var/cache/dev/twig/xxx.php, I have :
    `echo twig_var_dump($this->env, $context);`
    This is the dump function in the twig/twig.

    Have you already seen this problem ?