Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine
This tutorial has a new version, check it out!

Profiler: Your Debugging Best Friend

Video not working?

It looks like your browser may not support the H264 codec. If you're using Linux, try a different browser or try installing the gstreamer0.10-ffmpeg gstreamer0.10-plugins-good packages.

Thanks! This saves us from needing to use Flash or encode videos in multiple formats. And that let's us get back to making more videos :). But as always, please feel free to message us.

We're making some pretty serious progress - you should be proud! Let's check out what files we've modified:

git status

Add everything:

git add .

And commit:

git commit -m "Added some Twiggy goodness"

Installing the Profiler

Because now I want to install one of my absolute favorite tools in Symfony. Run:

composer require profiler --dev

I'm using --dev because the profiler is a tool that we'll only need while we're developing: it won't be used on production. This means Composer adds it to the require-dev section of composer.json. This isn't that important, but this is the right way to do it.

Tip

In newer projects, instead of symfony/profiler-pack, you may see 3 packages here, including symfony/web-profiler-bundle. That's ok! We'll explain what's going on in a few minutes.

69 lines composer.json
{
... lines 2 - 15
"require-dev": {
"symfony/profiler-pack": "^1.0"
},
... lines 19 - 67
}

And... at this point, it should be no surprise that this configured a recipe! Run:

git status

Hello Web Debug Toolbar

Oh, wow! It added three config files. Thanks to these, the feature will work instantly. Try it: back at your browser, refresh the page. Hello web debug toolbar! The fancy little black bar on the bottom. This will now show up on every HTML page while we're developing. It tells us the status code, which controller and route were used, speed, memory, Twig calls and even more icons will show up as we start using more parts of Symfony.

And Hello Profiler

The best part is that you can click any of these icons to jump into... the profiler. This is basically the expanded version of the toolbar and it is packed with information about that page load, including request info, response info and even a super-cool performance tab. This is not only a nice way to debug the performance of your app, it's also a great way to... just understand what's going on inside Symfony.

There are other sections for Twig, configuration, caching and eventually there will be a tab to debug database queries. By the way, this isn't just for HTML pages: you can also access the profiler for AJAX calls that you make to your app. I'll show you how later.

The dump() and dd() Functions

When we installed the profiler, we also got one other handy tool called dump(). I'll click back a few times to get to the page. Open up the controller: src/Controller/QuestionController.php.

Imagine we want to debug a variable. Normally I'd use var_dump(). Instead, use dump() and let's dump the $slug and... how about $this object itself.

... lines 1 - 8
class QuestionController extends AbstractController
{
... lines 11 - 21
public function show($slug)
{
... lines 24 - 29
dump($slug, $this);
... lines 31 - 35
}
}

When we refresh, woh! It works exactly like var_dump() except... way more beautiful and useful. The controller apparently has a container property... and we can dig deeper and deeper.

If you're really lazy... like most of us are... you can also use dd() which stands for dump() and die().

... lines 1 - 8
class QuestionController extends AbstractController
{
... lines 11 - 21
public function show($slug)
{
... lines 24 - 29
dd($slug, $this);
... lines 31 - 35
}
}

Now when we reload... it dumps, but also kills the page. We've now perfected dump-and-die-driven development. I think we should be proud?

Installing the debug Package

Change that back to dump()... and let's just dump() $this.

... lines 1 - 8
class QuestionController extends AbstractController
{
... lines 11 - 21
public function show($slug)
{
... lines 24 - 29
dump($this);
... lines 31 - 35
}
}

There's one other library that we can install for debugging tools. This one is less important - but still nice to have. At your terminal, run:

composer require debug

This time I'm not using --dev because this will install something that I do want on production. It installs DebugBundle - that's not something we need on production - but also Monolog, which is a logging library. And we probably do want to log things on production.

Composer Packs?

Before we talk about what this gave us, check out the name of the package it installed: debug-pack. This is not the first time that we've installed a library with "pack" in its name.

A "pack" is a special concept in Symfony: it's sort of a "fake" package whose only job is to help install several packages at once. Check it out: copy the package name, find your browser, and go to https://github.com/symfony/debug-pack. Woh! It's nothing more than a composer.json file! This gives us an easy way to install just this package... but actually get all of these libraries.

Tip

In my project, installing a "pack" would add just one line to composer.json: symfony/debug-pack. But starting in symfony/flex 1.9, when you install a pack, instead of adding symfony/debug-pack to composer.json, it will add these 5 packages instead. You still get the same code, but this makes it easier to manage the package versions.

So thanks to this, we have two new things in our app. The first is a logger! If we refresh the page... and click into the profiler, we have a "Logs" section that shows us all the logs for that request. These are also being saved to a var/log/dev.log file.

The second new thing in our app is... well... if you were watching closely, the dump() is gone from the page! The DebugBundle integrates the dump() function even more into Symfony. Now if you use dump(), instead of printing in the middle of the page, it puts it down here on the web debug toolbar. You can click it to see a bigger version. It's not that important... just another example of how Symfony gets smarter as you install more stuff.

The server:dump Command

Oh, while we're talking about it, the DebugBundle gave us one handle new console command. At your terminal, run:

php bin/console server:dump

This starts a little server in the background. Now whenever dump() is called in our code, it still shows up on the toolbar... but it also gets dumped out in the terminal! That's a great way to see dumped data for AJAX requests. I'll hit Control-C to stop that.

Unpacking Packs

Oh, and about these "packs", if you open your composer.json file, the one problem with packs is that we only have debug-pack version 1.0 here: we can't control the versions of the packages inside. You just get whatever versions the pack allows.

70 lines composer.json
{
... lines 2 - 3
"require": {
... lines 5 - 9
"symfony/debug-pack": "^1.0",
... lines 11 - 15
},
... lines 17 - 68
}

If you need more control, no problem... just unpack the pack:

composer unpack symfony/debug-pack

That does exactly what you expect: it removes debug-pack from composer.json and adds its underlying packages, like debug-bundle and monolog. Oh, and because the profiler-pack is a dependency of the debug-pack, it's in both places. I'll remove the extra one from require.

74 lines composer.json
{
... lines 2 - 3
"require": {
"php": "^7.2.5",
"ext-ctype": "*",
"ext-iconv": "*",
"easycorp/easy-log-handler": "^1.0.7",
"sensio/framework-extra-bundle": "^5.5",
"symfony/console": "5.0.*",
"symfony/debug-bundle": "5.0.*",
"symfony/dotenv": "5.0.*",
"symfony/flex": "^1.3.1",
"symfony/framework-bundle": "5.0.*",
"symfony/monolog-bundle": "^3.0",
"symfony/profiler-pack": "*",
"symfony/twig-pack": "^1.0",
"symfony/var-dumper": "5.0.*",
"symfony/yaml": "5.0.*"
},
... lines 21 - 72
}

Next, let's make our site prettier by bringing CSS into our app.

Leave a comment!

43
Login or Register to join the conversation
Default user avatar
Default user avatar Joshua Lowe | posted 3 years ago

For some reason, I have the profiler installed with the bottom bar, but when I put the dump call in the controller, it does not show those values at the top of the page. Instead, it still renders the page as before. I can access the dump information by clicking the debug toolbar however. Any suggestions?

Oops, just realized I already had debug installed!

1 Reply

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!

Reply
Ewald V. Avatar
Ewald V. Avatar Ewald V. | posted 3 years ago

I've build some pretty advanced applications in Symfony in the last 7 years, but it's fun to see that even beginners tutorials can teach me something. I didn't know about the debug-bundle until now!

1 Reply

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

1 Reply
Ewald V. Avatar

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

1 Reply
Default user avatar
Default user avatar Denys | posted 1 year ago | edited

Hi, guys!

I have:
Command "symfony:unpack" is deprecated, Symfony packs are always unpacked now.

How to unpack "symfony/debug-pack"?

Thank you!!!

Reply

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!

Reply
Frédéric H. Avatar
Frédéric H. Avatar Frédéric H. | posted 1 year ago

Running Symfony 6. After requiring profiler with composer, the web debug toolbar does not appear. It is listed as web-profiler-bundle and debug-bundle rather than package as the tooltip suggested. The dump command works as intended initially and simply vanishes along with the toolbar when debug is installed. Lastly the composer unpack command returns "Command "unpack" is not defined" in the CLI. Not sure where my issue is.

Reply

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!

Reply
Frédéric H. Avatar
Frédéric H. Avatar Frédéric H. | weaverryan | posted 1 year ago

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.

Reply

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!

Reply
Игорь П. Avatar
Игорь П. Avatar Игорь П. | posted 1 year ago

What changes should be done to run it in symfony 6?

After adding dump($slug, $this);

I've got
Warning: session_id(): Session ID cannot be changed after headers have already been sent

Reply

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!

1 Reply
Elchanan B. Avatar
Elchanan B. Avatar Elchanan B. | posted 2 years ago | edited

Hey, in flex > 1.9, what should I move to require-dev instead of debug-pack,
is that symfony/stopwatch and symfony/web-profiler-bundle?

Reply

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!

1 Reply
Lucian C. Avatar
Lucian C. Avatar Lucian C. | posted 2 years ago

I got the profiler working and I had the tool bar which was very useful. However, after installing the debug packages, the toolbar disappeared and I'm not too sure why and I've tried following some forums online but I can't seem to get it back. I've even tried reinstalling etc. but not luck so far. 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

Even after installing it... Any help would be greatly appreaciated. If it's any help I'm running Debian 10 on WSL2. Thanks!

Reply

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!

Reply
Benoit-L Avatar
Benoit-L Avatar Benoit-L | posted 2 years ago

Hello,

when I want
to remove the Symfony/debug-pack I have the following message : Package
Symfony/debug-pack is not installed; wich seems to me strange as I did
before the composer require debug.

Reply

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!

Reply
Alessandro V. Avatar
Alessandro V. Avatar Alessandro V. | posted 2 years ago

Hi, it worked well for a while but when i added content to my page the debug has broken and now it says "An error occurred while loading the web debug toolbar."

Reply

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!

Reply

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.

Reply

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!

Reply
Maike L. Avatar
Maike L. Avatar Maike L. | posted 2 years ago
php bin/console server:dump

does not work for me.
I keep getting the warning

Unable to decode a message from 865 client


and the localhost (9912) does not connect :(

Reply
Albert V. Avatar

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

Reply

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!

Reply
Albert V. Avatar
Albert V. Avatar Albert V. | Victor | posted 1 year ago

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!!

Reply

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

Cheers!

Reply

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!

Reply
Georg H. Avatar
Georg H. Avatar Georg H. | posted 2 years ago | edited

Oh yes, the profiler toolbar is very useful. I wonder why it disappears on pages that contain a JavaScript block. The script sends a 'click' to a button, at the end of $(document).ready();

Reply

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!

Reply
Default user avatar
Default user avatar Georg | Victor | posted 2 years ago | edited

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

Reply

Hey Georg,

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

Cheers!

Reply
Sung L. Avatar
Sung L. Avatar Sung L. | posted 2 years ago | edited

I got error from security checker when installing profiler.

`
➜ composer require profiler --dev 14s
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.*"
Nothing to install or update
Generating optimized autoload files

Run composer recipes at any time to see the status of your Symfony recipes.

Executing script cache:clear [OK]
Executing script assets:install public [OK]
Executing script security-checker security:check [KO]
[KO]
Script security-checker security:check returned with error code 1
!! Symfony Security Check Report
!! =============================
!!
!! 1 packages have known vulnerabilities.
!!
!! symfony/http-kernel (v5.1.4)
!! ----------------------------
!!
!! * [CVE-2020-15094][]: Prevent RCE when calling untrusted remote with CachingHttpClient
!!
!! [CVE-2020-15094]: https://symfony.com/cve-2020-15094
!!
!! Note that this checker can only detect vulnerabilities that are referenced in the SensioLabs security advisories database.
!! Execute this command regularly to check the newly discovered vulnerabilities.
!!
Script @auto-scripts was called via post-update-cmd

Installation failed, reverting ./composer.json to its original content.
`

Reply

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!

Reply
Sung L. Avatar

Thanks Diego!
That worked.

1 Reply
Azar A. Avatar

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

Reply

Hey Azar A.

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

Cheers!

Reply
Stiev Avatar

I somehow fail to install the profiler. It doesnt add the line to the composer.json and in git it looks like it installs it and then uninstalls it again? I tried to add the line myself but it still won't work, i guess there are files missing that the composer re-uninstalled?

Reply

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!

Reply
Stiev Avatar
Stiev Avatar Stiev | Victor | posted 3 years ago | edited

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

Reply

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!

1 Reply
Stiev Avatar

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

1 Reply
Cat in space

"Houston: no signs of life"
Start the conversation!

This tutorial also works great for Symfony 6!

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.3.0 || ^8.0.0",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "easycorp/easy-log-handler": "^1.0.7", // v1.0.9
        "sensio/framework-extra-bundle": "^6.0", // v6.2.1
        "symfony/asset": "5.0.*", // v5.0.11
        "symfony/console": "5.0.*", // v5.0.11
        "symfony/debug-bundle": "5.0.*", // v5.0.11
        "symfony/dotenv": "5.0.*", // v5.0.11
        "symfony/flex": "^1.3.1", // v1.17.5
        "symfony/framework-bundle": "5.0.*", // v5.0.11
        "symfony/monolog-bundle": "^3.0", // v3.5.0
        "symfony/profiler-pack": "*", // v1.0.5
        "symfony/routing": "5.1.*", // v5.1.11
        "symfony/twig-pack": "^1.0", // v1.0.1
        "symfony/var-dumper": "5.0.*", // v5.0.11
        "symfony/webpack-encore-bundle": "^1.7", // v1.8.0
        "symfony/yaml": "5.0.*" // v5.0.11
    },
    "require-dev": {
        "symfony/profiler-pack": "^1.0" // v1.0.5
    }
}
userVoice