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.

Tip

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-04-16 Victor Bocharsky

    Hey Petru,

    See "framework.ide" option: https://symfony.com/doc/cur... . Looks like Windows requires PhpStormProtocol to get it working with PhpStorm, but it should work by default in browser. Anyway, you can change this value to use PhpStorm or any of your favorite IDE / text editor which I think will be much useful instead of just showing it in browser.

    Cheers!

  • 2018-04-15 Petru Lebada

    Hello,

    I clicked on the controller::show in profiler and it gives me an error:

    No route found for "GET /myproject/public/_profiler/open" (from "http://localhost/myproject/public/news/why-asteroids-taste-like-bacon")

    My dev env is windows and im using apache on xampp

    Any ideas how i can fix this?

  • 2018-03-27 Victor Bocharsky

    Aha, this "install-recipes" command came from Symfony Flex v1.0.76: https://github.com/symfony/... . And really, to see it you need to run composer *inside* your project dir. Thanks again ;)

    Cheers!

  • 2018-03-26 Schyzophrenic

    Victor Bocharsky I am using composer Composer version 1.6.3 2018-01-31 16:28:17
    Insterestingly, the "install-recipes" option is only available if you run composer in the project directory. Not sure how composer is plugged with symfony but there is definitely something going on here :)

  • 2018-03-26 Victor Bocharsky

    Hey Schyzophrenic ,

    Thanks for sharing your solution! Yeah, looks like Twig is missing in your system. But what version of Composer do you have? Because I don't see "install-recipes" command in mine :) Probably it comes with a Composer plugin? What's the plugin name?

    Cheers!

  • 2018-03-25 Schyzophrenic

    If anyone runs through this issue, I fixed it by running
    composer install-recipes.

    i apparently had a missing recipe for twig (No idea how this occured...)

  • 2018-03-25 Schyzophrenic

    Hello,
    It seems that running the composer require profiler creates an issue:
    Executing script cache:clear [KO]
    [KO]
    Script cache:clear returned with error code 1
    !!
    !! In CheckExceptionOnInvalidReferenceBehaviorPass.php line 32:
    !!
    !! The service "web_profiler.controller.profiler" has a dependency on a non-existent service "twig".

    Not sure where this service is supposed to be defined in the new SF4 structure...

    Just to add: This is really odd as I created another app to test out and it works well if I go through all the require commands again.
    I tried to "remove" and then require again but no luck... Very odd. Any idea?

  • 2018-03-05 Victor Bocharsky

    Hey Jeroen,

    Thanks for sharing it! Looks like we use Twig v2.4.4 in this screencast

    Cheers!

  • 2018-03-03 Jeroen van den Nieuwenhuisen

    Edit: This issue is fixed with twig with the new twig version 2.4.6 :-)

    The problem is in the file Twig_Profiler_NodeVisitor_Profiler. I change line 56 from:

    return sprintf('__internal_%s', hash('sha256', __METHOD__));

    to:

    return sprintf('__internal_%s', hash('sha256', $this->extensionName));

    And after clearing the twig cache it works again.

  • 2018-03-03 Jeroen van den Nieuwenhuisen

    I am getting the following error after the command composer require profiler --dev and refreshing the show page.

    Twig_Error_Runtime
    An exception has been thrown during the rendering of a template ("Notice: Undefined offset: 0").

  • 2018-02-20 Diego Aguiar

    Hey @Alvaro

    I think your dump format is uglier (or different) because you have not installed "xdebug" on your server, but don't worry about it, in the next video, Ryan teaches how to use the "debug" pack which improves the "dump" format a lot more than "xdebug"

    Cheers!

  • 2018-02-20 Alvaro

    When insert {{ dump() }} in show.html.twig the content of the array it´s not shown formatted like in the video. Am I missing something?

  • 2018-01-29 weaverryan

    What I *should* have done was dump($slug, $this);die; :). The problem is simply that the content from the dump is causing session warnings, which we don't really care about because we're just dumping some debug code. It didn't show up on my screen due to some slightly different PHP settings. Anyways, it's always unnerving to see warnings ;).

    Cheers!

  • 2018-01-27 Simon Waldburger

    Got the same error. But after installing the next package "debug" (see next lesson) it got fixed!

  • 2018-01-26 Gerard Doets

    First of all: Thank you for such a great explanation (and for the startrek references).
    I ran into this error, after I added the dump($slug, $this); on line 30 in the ArticleController.php and the {{ dump() }} in the show.html.twig I got an

    HTTP 500 error: "Failed to start the session because headers have already been sent by "C:\xampp\htdocs\symfony\the_spacebar\vendor\symfony\var-dumper\Dumper\AbstractDumper.php" at line 181.
    "
    Thanks!

  • 2018-01-25 weaverryan

    Hey Łukasz!

    I'm glad you figured it out :). The Web Debug Toolbar should work fine with Apache, but you may need to add the .htaccess file. You can do that by running composer require symfony/apache-pack.

    Cheers!

  • 2018-01-23 Łukasz

    It was problem with Apache server. It doesn't work together.

  • 2018-01-23 Łukasz

    Hello, I have a problem with profiler. 'An error occurred while loading the web debug toolbar. Open the web profiler.' After clicking 'Open the web profiler' shows 404 error page. I have 5 console errors on Chrome 'Failed to load resource: the server responded with a status of 404 (Not Found) ' for '/_wdt/05cb53' directory. Installation process was ended succesfull.

  • 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.

    Cheers!

  • 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 :).

    Cheers!

  • 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?

    Cheers!

  • 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