Profiler: Your Debugging Best Friend

Hey Joshua Lowe!

It sounds like you figured it out :). This is a feature - but it can be a bit surprising. When you have the "debug" pack, it provides a "better integration" with the dump() function and the web debug toolbar - and puts the dump *there* instead of add the top of the page.

Cheers!

In that case, you will love this tutorial: https://symfonycasts.com/sc...
Cheers!

Finished it yesterday and you were right, that was an amazing tutorial!

Hey Denys,

As it's said in the message you shared, Symfony packs are always unpacked by default now, so you just need to require a package and it will be unpacked automatically by Symfony Flex Composer plugin. But you probably need to upgrade your Symfony Flex dependency just in case, I don't remember to which minimum version, so I'd recommend you to upgrade to the latest in 1.x or 2.x branches.

Cheers!

Hey @Antonin!

Ok, there are a bunch of things going on here :). Let me handle things... in kind of a different order.

Lastly the composer unpack command returns "Command "unpack" is not defined" in the CLI

Starting with Symfony Flex 1.9, when you install a pack, it is automatically unpacked - you can read more about it in the "Tip" in this section: https://symfonycasts.com/screencast/symfony/profiler#composer-packs

This is a good change, and it basically means that you don't need to bother running the unpack command (in fact, as you saw, that command no longer exists). It also means that you won't see symfony/profiler-pack or symfony/debug-pack in your composer.json file, because these were already & automatically unpacked.

The dump command works as intended initially and simply vanishes along with the toolbar when debug is installed

This is expected :). Assuming your web profiler actually works (we'll get to that in a minute), as soon as you have both "Debug" and "Web profiler" installed, if you dump($someVar), instead of it being printed at the top of your screen, you'll have a little "target" icon on your web debug toolbar and the dump will be inside of THAT. This is cool... but it is a little surprising/unexpected the first time you see it, because it looks like your dump just disappears. I'm not sure if I mention that in THIS tutorial - but you can see an example at the very end of this video in the next tutorial: https://symfonycasts.com/screencast/symfony-fundamentals/prod-environment

After requiring profiler with composer, the web debug toolbar does not appear

This is the trickiest item, because I don't have an explanation for this! But, there are a few things we can look at to debug:

A) Does the page that you're going to have a full HTML layout? Or, another way to ask: are you trying to access a page that renders a template that extends base.html.twig? The web debug toolbar is only added to full HTML pages.

B) Assuming you are going to a full HTML page, then here's how the system should work. After your page finishes loading, Symfony makes an Ajax request for the web debug toolbar. If that Ajax call fails for some reason, you should see an error at the bottom of the screen where the toolbar would normally be. I would check your browser's console to see if you have a JavaScript error and if you can see any Ajax call being made: it will be to a URL that starts with /_profiler

C) Finally, to see if the profiler/web debug toolbar system is working at all, you can try going to /_profiler. If you see a the "profiler" showing you a list of recent requests, it is working (and then we need to figure out why the web debug toolbar isn't working). If you get an error or a 404 page, then that will help us debug in another direction.

Let me know what you find out!

Cheers!

Thank you for the response. I have the full setup with twig as far as I can see, I have the base.html.twig and show.html.twig, the template I am displaying, There are no javascript/AJAX error on the page or in the browser console.

It looks like the profiler is working on /_profiler and the web toolbar will show up on the error 404 page when I type an invalid route in the URL. Still does not appear on my html page.

Hey @Antonin!

Hmm. So we know that the web debug toolbar IS working, thanks to you noting that it works on the 404 page (and /_profiler is working). Here's how the process *should* work, which may highlight what's going wrong:

A) Right before Symfony finishes, it looks at the response that's about to be returned. Specifically, it looks for the closing body tag - https://github.com/symfony/... . IF that is found, it injects a bunch of JavaScript onto your page. You can see this if you "view source" in your browser - it'll be a bunch of ugly JavaScript right at the bottom of the HTML. So I would first check to see if this code is there.

B) That JavaScript will make an Ajax request for the Ajax web debug toolbar and then place it onto the page. It's not usual, but it's possible that this AJAX request is failing. I'd check your network tools: look for a request starting with /_wdt.

Overall, it's gotta be something subtle: something unexpected is short-circuiting the process. The most common reason for this is that your page is missing the closing body tag... but since you said you're extending base.html.twig, that seems unlikely. Still, part (A) above will prove or disprove that part: if you see all the wdt JavaScript on the bottom of the HTML, then you know that this is NOT the problem.

Cheers!

Hey Игорь П.

That has nothing with Symfony 6, just ignore this warning, it will go away after you install debug bundle

BTW just as a reminder, this course was built with Symfony 5 and we do not recommend to update course deps to latest versions to have issue less learning =)

Cheers!

Hey there!

You can see all the packages that gives you debug-pack here: https://packagist.org/packa... . I'm talking about these packages:
- symfony/debug-bundle
- symfony/monolog-bundle
- symfony/profiler-pack
- symfony/var-dumper

You should decide yourself what you don't need in the prod mode and need only for debug purposes, but usually it's just:
- symfony/debug-bundle
- symfony/profiler-pack
- symfony/var-dumper

The symfony/monolog-bundle is used in the prod mode, so this should be in "require" section :)

Cheers!

Hey @Lucian Chev!

Hmm... interesting! I can't think of why this would happen - and it sounds like you've tried the stuff I would first try (re-installing, etc). Let's figure this out! First:

Also when try to unpack the debug-pack using:
composer unpack symfony/debug-pack
I get the error :
Package symfony/debug-pack is not installed

Don't worry about this :). This is due to a change that was made in Symfony Flex after this tutorial was created. We have a note about it around 4:28 in this video (in this section https://symfonycasts.com/screencast/symfony/profiler#composer-packs ). It's actually a nice change (though it does make uninstalling packs harder). Basically, now, after you install symfony/debug-pack, instead of just having symfony/debug-pack added to your composer.json, Symfony Flex adds the 4 libraries that are IN this pack to your composer.json - https://github.com/symfony/debug-pack/blob/cfd5093378e9cafe500f05c777a22fe8a64a9342/composer.json#L7-L10 (and actually, one of those is the profiler-pack... which itself would do the same thing - it would add its specific libraries to your composer.json file, instead of profiler-pack).

Anyways, this is not the root of your problem - but I you to know that you're not doing anything wrong here :).

Ok, back to the profiler! There are 3 things that make the web debug toolbar work (and normally they're all handled automatically for you with the recipes, but maybe something went wrong):

1) You need to have symfony/web-profiler-bundle installed. Check that by running composer show symfony/web-profiler-bundle. Installing debug should not have caused this to get removed, but since we know something seems to have gone wrong, let's consider all possibilities ;).

2) This bundle needs to be enabled in your config/bundles.php file. Look for WebProfilerBundle in that file. Again, the recipe normally adds this automatically.

3) The bundle needs a config file. Actually, a config file and a routing file. The recipe should have added both. Look for them at config/packages/dev/web_profiler.yaml and config/routes/dev/web_profiler.yaml.

Let me know if any of these are missing! If they are... then something went wrong with the recipe system. I can't think of what, but I can try to replicate it to see if I can get the same bad behavior. To fix the issue (if the problem is 2 or 3), you can actually just re-install the bundle (which should trigger the recipe to re-install: composer remove symfony/web-profiler-bundle --dev then composer require symfony/web-profiler-bundle --dev.

Let me know what you find out!

Cheers!

Hey Benoit L.!

Ah yes! I know this! This is because Flex now automatically "unpacks" packs - we have a note about this in the tutorial. It means that after you run composer require debug to install symfony/debug-pack, it immediately "unpacks" it also - https://symfonycasts.com/screencast/symfony/profiler#unpacking-packs

This means that, after that operation is done, symfony/debug-pack is not in your composer.json file. Instead, the 3, 4, 5 (whatever it is) libraries that it requires are in composer.json. This is super great because it makes it much easier to control the specific packages and versions... but it does mean that you can't simply uninstall all of those with one command.

Cheers!

Hey Alessandro,

Wow, hm... Are you talking about web debug toolbar, right? If so - make sure the page has the valid HTML structure, i.e. contains closing body and html tags. Also, to know more about the problem - check the logs. Logs should explain that "An error occurred while loading the web debug toolbar." error, i.e. contain a real error.

I hope this helps!

Cheers!

I have the same problem after running composer require debug. HTML structure is ok, i got some error in dev.log :
php.CRITICAL: Uncaught Error: Typed property Symfony\Component\HttpKernel\Debug\FileLinkFormatter::$requestStack must not be accessed before initialization and dump is not in the toolbar offcourse.
if I remove dump($this) error is gone and everything works.

Hey Domagoj,

Did you download the course code and started from start/ directory following the instructions in the README.md file? Did you run "composer update" at some point for this project? It may cause some BC breaks unless you fix them manually.

Cheers!

Same here: I get '[debug] Unable to decode a message from 440 client. ["clientId" => 440]'

Hey Albert,

Hm, do you have this error on every dump in your project? Could you check another page, e.g. a page that completely works in your application, add a "dump()" statement somewhere and see if it works. If still does not work - probably you can try to upgrade your Symfony client and var dumper to the latest versions, maybe it will help to fix this problem. Btw, are you on Windows OS? OS also might be related, as also the web-server you're running your website, do you Symfony built-in web server? I.e. run the website with "symfony serve" command?

I hope this helps!

Cheers!

Hmm interesting. I've tried again and it works now, WTF.

I'm on a Mac, and I'm running the server with 'symfony serve'.
Never mind, thanks for the help, appreciated!!

Glad you got it working - let's just say it was... profiler zombies ;).

Cheers!

Hey Maike L.!

Hmm, I'm not sure what that could be! There error comes from here: https://github.com/symfony/...

It looks like something IS trying to send data to the "dump server" but it's corrupted in some way. The only thing I can think of is to add some debugging statements temporarily in that class to see what that "$message" object looks like. It might give us a clue!

Cheers!

Hey Georg,

Yeah, that's just your best friend when you're working with Symfony ;)

Hm, it should not disappear. Does you page contain contain </body></html> tags on the page where you don't have web debug toolbar (WDT)? Symfony automatically inject it in dev mode as soon as your HTML response has those closing "body" and "html" tags. If the page does not have those - it won't be injected. Btw, probably you have invalid HTML page? It may cause problems when you won't see the WDT.

Cheers!

Good tip! I missed the closing '>' of the <script> tag. Thanks a lot!

Hey Georg,

Ha, that was a wild guess, and we hit it ;) Glad to help!

Cheers!

Hey Sung L.

Since you installed the security-checker component it ran a command for checking vulnerabilities. It found one related to symfony/http-kernel, you just have to update it by running composer upgrade symfony/http-kernel and that should be it (unless it's not fixed yet)

Cheers!

Thanks Diego!
That worked.

Hey Diego!
It doesn't work, still error 403

Executing script security-checker security:check [KO]
[KO]
Script security-checker security:check returned with error code 1
!!
!! The web service failed for an unknown reason (HTTP 403).
!!
!!
Script @auto-scripts was called via post-update-cmd

Hey Azar A.

The SecurityChecker library has been deprecated. You can check your project through Symfony CLI
just run symfony security:check

Cheers!

Hey Steffen,

Probably some error is happened during the installation and Composer revert composer.json's content back. Looks closer to the errors in the output. Or could you show us what exactly command you're trying to execute and the full console output you get? We will try to help more.

Cheers!

Hey Victor, thank you for your time,

I am super confused now, because i shut down my laptop to take a break and as i restarted everything and looked at my page, the profiler worked. After i tried to install the profiler the first time, i added+commited the changes, restarted Chrome and the server and even the IDE, nothing made any difference.

The only thing i noticed, is that there are no changes to the composer.json file since the last time i checked, so it has been changed all along? Probably the composer removed the profiler because it was a duplicate, but i still dont know what changed now. Anyway, here is the git output:

`Stiev@LAPTOP-3TLOOD2L MINGW64 /c/SymfonyFiles/project_name (master)
$ composer require profiler --dev
Using version ^1.0 for symfony/profiler-pack
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Restricting packages listed in "symfony/symfony" to "5.1.*"
Package operations: 1 install, 0 updates, 0 removals

• Installing symfony/profiler-pack (v1.0.4): Loading from cache
  Writing lock file
  Generating optimized autoload files
  36 packages you are using are looking for funding.
  Use the composer fund command to find out more!
  Executing script cache:clear [OK]
  Executing script assets:install public [OK]

Unpacked symfony/profiler-pack dependencies
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 0 installs, 0 updates, 1 removal

• Removing symfony/profiler-pack (v1.0.4)
  36 packages you are using are looking for funding.
  Use the composer fund command to find out more!
  `

And this is from my composer.json
` "require-dev": {

    "symfony/stopwatch": "^5.1",
    "symfony/twig-bundle": "^5.1",
    "symfony/web-profiler-bundle": "^5.1"
},

`
Just noticing as i read over it again: Is "symfony/web-profiler-bundle" here the "symfony/profiler-pack" from the video? That would explain the missing line

Hi Stiev!

I can answer this :). And sorry about the confusion! Starting with symfony/flex 1.9 (released a few days ago), when you install a "pack", Symfony flex automatically "unpacks" it. Basically, here's how it works:

A) You ran composer require profiler
B) Because this is a Flex alias, it installs symfony/profiler-pack

This is where things become different in Flex 1.9:

C) [Before Flex 1.9] The symfony/profiler-pack would be added to composer.json. Because this package depends on 3 other packages (https://github.com/symfony/... ) Composer would naturally *also* install those 3 packages. But you would only see symfony/profiler-pack in your composer.json.

C) [Starting with Flex 1.9] Flex notices that this is a "pack". And then, instead of adding symfony/profile-pack to your composer.json, it looks at the pack's dependencies (these again https://github.com/symfony/... ) and puts *those* 3 packages into your composer.json instead.

The end result is the same: your project has all the code from the 3 "profiler" packages. The difference is simply how your composer.json file looks. And the change is a *good* change. By having the 3 packages in your composer.json file (instead of the 1), in the future, you can manage the versions of these packages independently.

Packs were always just "an easy way to install multiple packages with one command". Starting in Flex 1.9, this is even *more* true: you require 1 package, but ultimately, several are installed and added to your composer.json file.

Let me know if that makes sense - we'll add a video note :).

Cheers!

Thanks for the explanation, i think understood that part now

I think I figured out why the profiler didn't show up, too. It requires <body> tags and i tested it with the controller pages that did not have these. Worked fine as soon as i added them