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

Profiler: El mejor amigo de tu Debugger

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.

Estamos teniendo un muy buen progreso - Deberías estar orgulloso! Veamos qué archivos hemos modificado:

git status

Agrega Todo:

git add .

Y haz commit:

git commit -m "Added some Twiggy goodness"

Instalando el Profiler

Porque ahora quiero instalar una de mis herramientas de symfony favoritas. Corre:

composer require profiler --dev

Estoy usando --dev porque el profiler es una herramienta que sólo necesitaremos mientras estamos en desarrollo: No será usada en producción. Esto significa que Composer lo agrega a la sección require-dev de composer.json. No es tan importante, pero es la forma correcta de hacerlo.

Tip

En proyectos nuevos, en vez de symfony/profiler-pack, podrías ver 3 paquetes aquí, incluyendo symfony/web-profiler-bundle. ¡No hay problema! Explicaremos esto en algunos minutos.

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

Y... en este punto, no debería sorprendernos que esto ha instalado una receta!

Corre:

git status

Saluda a la Barra de Herramientas Web Debug

¡Oh, wow! Agregó tres archivos de configuración. Gracias a éstos, el módulo funcionará al instante. Pruébalo: de vuelta a tu navegador, refresca la página. ¡Saluda a la barra de herramientas debug! La dichosa barrita en la parte inferior. Ahora esto aparecerá en cada página HTML mientras estamos desarrollando. Nos muestra el código de status, cuál controlador y ruta usamos, velocidad, memoria, llamadas Twig e incluso más íconos aparecerán a medida que empezamos a usar más partes de symfony.

Y Saluda al Profiler

La mejor parte es que puedes hacer click en cualquier de estos íconos para saltar... al profiler. Esta es básicamente la version expandida de la barra de herramientas y está llena de información sobre la carga de la página, incluyendo la información del request, response e incluso una maravillosa pestaña de performance. Esta no solo es una buena manera de hacer un debug del performance de tu aplicación, también es una gran manera... de simplemente entender qué está sucediendo dentro de Symfony.

Hay otras secciones para Twig, configuración, cacheo y eventualmente habrá una pestaña para ver las queries a la base de datos. A propósito, esto no es solo para páginas HTML: también puedes acceder al profiler para las llamadas AJAX que haces a tu app. Te mostraré cómo más adelante.

Las Funciones dump() y dd()

Cuando instalamos el profiler, también obtuvimos otra herramienta útil llamada dump(). Haré click en atrás un par de veces para ir a la página. Abre el controlador: src/Controller/QuestionController.php.

Imagina que queremos ver una variable. Normalmente, usaría var_dump(). En vez de ello, usa dump() y vamos a imprimir el $slug y... qué tal el propio objeto $this.

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

Cuando refrescamos, órale! Funciona exactamente como var_dump() excepto... muchísimo más bello y útil. El controlador aparentemente tiene una propiedad llamada container... y podemos ir más y más profundo.

Y si eres muy haragán... Cómo la mayoría de nosotros lo es... también puedes usar dd() lo cual significa dump() y luego die().

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

Ahora cuando refrescamos... hace el dump, pero también termina la ejecución en la página. Hemos perfeccionado el desarrollo basado en dump-and-die. ¿Creo que deberíamos estar orgullosos?

Instalando el Paquete de Debug

Cámbialo de vuelta a dump()... y sólo hagamos dump($this).

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

Hay otra librería que podemos instalar para herramientas de debug. Esta es menos importante - pero de todas formas buena para tener en cuenta. En tu terminal, corre:

composer require debug

Esta vez no estoy usando -- dev porque esto instalará algo que sí quiero en producción. Esto instala el DebugBundle - eso no es algo que necesitemos en producción - pero también instala Monolog, que es una librería de logueo. Y probablemente sí querramos loguear cosas en producción.

Paquetes Composer?

Antes de hablar de lo que esto nos dió, hecha un vistazo al nombre del paquete que instaló: debug-pack. Esta no es la primera vez que hemos instalado una librería con "pack" en su nombre.

Un "pack" es un concepto especial en Symfony: Es como un tipo de paquete "falso" cuya única función es ayudar a instalar varios paquetes al mismo tiempo. Echale un vistazo: copia el nombre del paquete, busca tu navegador, y ve a https://github.com/symfony/debug-pack. Orale! No es nada más que un archivo composer.json! Esto nos da una manera fácil de instalar solo este paquete... pero en realidad obtener todas estas librerías.

Tip

En mi proyecto, instalar un "pack" solo agregaría una linea a composer.json: symfony/debug-pack. Pero a partir de symfony/flex 1.9, cuando instalas un pack, en vez de agregar symfony/debug-pack a composer.json, agregará 5 paquetes. Aún obtienes el mismo código, pero esto facilita el manejo de las versiones de los paquetes.

Así que gracias a esto, tenemos dos nuevas cosas en nuestra aplicación. La primera es un logguer! Si refrescamos la página... y hacemos click en el profiler, tenemos la sección "Logs" que nos muestra todos los logs para este request. Estos también son guardados en el archivo var/log/dev.log.

La segunda cosa nueva en nuestra aplicación es... bueno... si miraste atentamente, el dump() desapareció de la página! El DebugBundle integra la función dump() incluso más dentro de Symfony. Ahora si usamos dump(), en vez de imprimirlo en la mitad de la página, lo pone aquí abajo en la barra de herramientas debug. Puedes hacer click en ella para ver una versión más grande. No es tan importante... Es solo otro ejemplo de cómo Symfony se vuelve más listo a medida que instalas más cosas.

El Comando server:dump

Oh, ya que estamos hablando de ello, el DebugBundle nos dió un nuevo comando de la consola. En tu terminal, corre:

php bin/console server:dump

Esto inicia un pequeño servidor detrás de escena. Ahora, siempre que se ejecute dump() en nuestro código, aún se muestra en nuestra barra de herramientas... Pero también se imprime en la terminal! Esa es una excelente manera de ver información pedida en los requests de AJAX. Presionaré Control-C para detenerlo.

Expandiendo Packs

Oh, y hablando de estos "packs", si abres el archivo composer.json, el único problema con los packs es que aquí sólo vemos debug-pack version 1.0: no podemos controlar las versiones de los paquetes de dentro. Simplemente obtienes cualquiera que sea la versión que el pack solicita.

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

Si necesitas mas control, no hay problema... Sólo extrae el pack:

composer unpack symfony/debug-pack

Eso hace exactamente lo que esperas: quita debug-pack de composer.json y agrega los paquetes subyacentes, como debug-bundle y monolog. Ah, y como el profiler-pack es una dependencia del debug-pack, está en ambos lugares. Removeré el extra del 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
}

A continuación, hagamos nuestro sitio más bello incluyendo CSS en nuestra aplicación.

Leave a comment!

43
Login or Register to join the conversation
Default user avatar
Default user avatar Joshua Lowe | posted hace 2 años

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 hace 2 años

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

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 hace 1 año

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/sc...

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/sc...

> 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 hace 1 año

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 hace 1 año

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 hace 1 año

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 hace 1 año

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/sc... ). 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/... (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 hace 2 años

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/sc...

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 hace 2 años

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 hace 2 años
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

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 hace 2 años

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

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

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

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!

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