Web Debug Toolbar & the Profiler!

Make sure you've committed all of your changes - I already did. Because we're about to install something super fun! Like, floating around space fun! Run:

composer require profiler --dev

The profiler - also called the "web debug toolbar" is probably the most awesome thing in Symfony. This installs a few packages and... one recipe! Run:

git status

Ok cool! It added a couple of configuration files and even some routes in the dev environment only that help the profiler work. So... what the heck is the profiler? Go back to your browser, make sure you're on the article show page and refresh! Voilà!

Hello Web Debug Toolbar!

See that slick black bar at the bottom of the page! That's the web debug toolbar! It's now automatically injected at the bottom of any valid HTML page during development. Yep, this JavaScript code makes an AJAX call that loads it.

Oh, and it's packed with info, like which route was matched, what controller was executed, execution time, cache details and even information about templates.

And as we install more libraries, we're going to get even more icons! But the really awesome thing is that you can click any of these icons to go into... the profiler.

Hello Profiler: The Toolbar's Powerful Sidekick

OoooOoo. This takes us to a totally different page. The profiler is like the web debug toolbar with a fusion reactor taped onto it. The Twig tab shows exactly which templates were rendered. We can also get detailed info about caching, routing and events, which we'll talk about in a future tutorial. Oh, and my personal favorite: Performance! This shows you how long each part of the request took, including the controller. In another tutorial, we'll use this to dig into exactly how Symfony works under the hood.

When you're ready to go back to the original page, you can click the link at the top.

Magic with The dump() Function

But wait, there's more! The profiler also installed Symfony's var-dumper component. Find ArticleController and go to showAction(). Normally, to debug, I'll use var_dump() to print some data. But, no more! Instead, use dump(): dump the $slug and also the controller object itself:

37 lines src/Controller/ArticleController.php
... lines 1 - 8
class ArticleController extends AbstractController
... lines 11 - 21
public function show($slug)
... lines 24 - 28
dump($slug, $this);
... lines 30 - 34

Ok, refresh! Beautiful, colored output. And, you can expand objects to dig deeper into them.


To expand all the nested nodes just press Ctrl and click the arrow.

Using dump() in Twig

The dump() function is even more useful in Twig. Inside the body block, add {{ dump() }}:

31 lines templates/article/show.html.twig
... lines 1 - 4
{% block body %}
{{ dump() }}
... lines 7 - 29
{% endblock %}

In Twig, you're allowed to use dump() with no arguments. And that's especially useful. Why? Because it dumps an associative array of all of the variables you have access to. We already knew we had title and comments variables. But apparently, we also have an app variable! Actually, every template gets this app variable automatically. Good to know!

But! Symfony has even more debugging tools! Let's get them and learn about "packs" next!

Leave a comment!

  • 2018-01-17 shing

    WOW! super fast reply and top marks!! for really clear explanation. WOW. That cleared up so presumptions in my head. Awesome,Thxs weaverryan

  • 2018-01-17 Bartosz

    Great :)
    Now everything is clear for me.

    Thank You Diego and Ryan.

  • 2018-01-17 weaverryan

    Hey @shing!

    Hmm, so we should update that page in the docs :). It really *should* be with --dev... but it *really* doesn't matter.

    So actually, the --dev flag has nothing to do with Symfony's "dev" environment or what environments it is activated in. All of that is decided in the package's recipe, which installs the exact same way with or without the --dev flag.

    Using the --dev flag is purely a *composer* thing. By using it, your dependencies will be added to a require-dev section of your composer.json file. And mostly, that makes no difference: when you run composer install, it downloads all of your dependencies from both the require and require-dev keys. So then... what *is* the point of --dev? Well, you're *supposed* to add libraries to require-dev that you *only* need during development (not on production). Why? Because then when you deploy to production, you can run composer install --no-dev to install ONLY the require deps (but not require-dev). Why would you do this? Because it gives your site a TINY performance boost to not have to worry about autoloading these files.

    Phew! So, the tl;dr is this:

    A) Recipes always install the same way, and --dev has nothing to do with the recipe system
    B) If you use --dev when installing a package that you only need during development, the only difference is that if use composer install --no-dev during deployment, you will get a small performance boost.


  • 2018-01-17 shing

    Hi, I did composer require profiler without the --dev flag, which is also what the symfony documentation recommended. (https://symfony.com/doc/cur... Everything seems to be installed correctly. config/bundles reflects that the profiler is in the dev environment.

    So my question is that, is there a way to check in the documentation, a flex component is installed with a default --dev flag, or only when the installation's done and check config/bundles for the environment.

    Thxs in advance

  • 2018-01-17 weaverryan

    Hey Bartosz!

    Ah, don't worry! Actually, there is nothing wrong at all :).

    1) For the first error - "Failed to start session" - that is because the dumped content (which you can see at the top of the page) is causing problems with the session. But it's not something to worry about :). If you add a die; after the dump(); statement, then you won't see this error (you'll only see the dumped content).

    2) For the ugly dump() in Twig, Diego is correct! Your dump() is uglier than mine because you don't have XDebug installed. I would recommend installing this, because it has several minor benefits. But... don't worry too much! If you watch the next video, we install *another* package which actually makes the dump() in Twig even prettier, even without XDebug :).


  • 2018-01-16 Bartosz

    Hi Diego, thx for interest in my case :)

    First the most simple thing, I use Symfony 4.0.3, Composer 1.5.1 and Firefox 57.0.4. Everything on Ubuntu 17.10.1 with PHP 7.1.11

    I'm not strong enough in Symfony to deal with all issues but I have double checked and I'm sure that there is no syntax mistake with double "$" in my code.
    I have made completely brand new Symfony project with just one Controller but result is the same... Any ideas?

  • 2018-01-16 Diego Aguiar

    Hey @Bartosz

    About your first problem, you have a double "$" at your slug variable.
    And, about the second one, I'm not 100% sure what is causing it, which Symfony version are you using? Do you have Xdebug enabled?


  • 2018-01-16 Bartosz

    I got a problem with dump() function. First example with dump($slug, $this) returns me an error.
    Here is first screenshot: https://prnt.sc/i1c8f3

    In second case, {{ dump() }} I also have some difficulties.
    Here is second screenshot: https://prnt.sc/i1ca9j