SymfonyCasts stands united with the people of Ukraine
gstreamer0.10-ffmpeg
gstreamer0.10-plugins-good packages.
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"
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.
| { | |
| ... 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
¡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.
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.
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?
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.
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.
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.
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.
| { | |
| ... 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.
| { | |
| ... 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.
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!
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!
Hi, guys!
I have:Command "symfony:unpack" is deprecated, Symfony packs are always unpacked now.
How to unpack "symfony/debug-pack"?
Thank you!!!
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!
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.
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!
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
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, in flex > 1.9, what should I move to require-dev instead of debug-pack,
is that symfony/stopwatch and symfony/web-profiler-bundle?
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!
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!
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!
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.
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!
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."
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.
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 :(
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!!
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!
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();
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!
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.
`
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!
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!
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?
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
composer fund command to find out more!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
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
// 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
}
}
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!