SymfonyCasts stands united with the people of Ukraine
gstreamer0.10-ffmpeg
gstreamer0.10-plugins-good packages.
Es hora de instalar nuestro segundo paquete. Y éste es divertido. Vamos a confirmar nuestros cambios primero: así será más fácil comprobar los cambios que hace la receta del nuevo paquete.
Añade todo:
git add .
Parece que está bien, así que... confirma:
git commit -m "Added some Tiwggy goodness"
Bonito.
Ahora ejecuta:
composer require debug
Así que sí, este es otro alias de Flex... y aparentemente es un alias desymfony/debug-pack. Y sabemos que un paquete es una colección de paquetes. Así que, en lugar de añadir esta única línea a nuestro archivo composer.json, si lo comprobamos, parece que ha añadido un nuevo paquete en la sección require -se trata de una biblioteca de registro- y... al final, ha añadido una nueva secciónrequire-dev con otras tres bibliotecas.
La diferencia entre require y require-dev no es demasiado importante: todos estos paquetes se descargaron en nuestra aplicación, pero como mejor práctica, si instalas una biblioteca que sólo está pensada para el desarrollo local, deberías ponerla enrequire-dev. ¡El pack lo hizo por nosotros! ¡Gracias pack!
De vuelta al terminal, ¡esto también instaló tres recetas! Ooh. Veamos qué han hecho. Limpio la pantalla y corro:
git status
Esto me resulta familiar: modificó config/bundles.php para activar tres nuevos bundles. De nuevo, los bundles son plugins de Symfony, que añaden más funciones a nuestra aplicación.
También añadió varios archivos de configuración al directorio config/packages/. Hablaremos más de estos archivos en el próximo tutorial, pero, a alto nivel, controlan el comportamiento de esos bundles.
¿Qué nos aportan estos nuevos paquetes? Para averiguarlo, dirígete a tu navegador y actualiza la página de inicio. ¡Santo cielo, Batman! Es la barra de herramientas de depuración web. Esto es una locura de depuración: una barra de herramientas llena de buena información. A la izquierda, puedes ver el controlador al que se ha llamado junto con el código de estado HTTP. También está la cantidad de tiempo que tardó la página, la memoria que utilizó y también cuántas plantillas se renderizaron a través de Twig: este es el bonito icono de Twig.
En el lado derecho, tenemos detalles sobre el servidor web local Symfony que se está ejecutando e información sobre PHP.
Pero aún no has visto la mejor parte: haz clic en cualquiera de estos iconos para saltar al perfilador. Esta es la barra de herramientas de depuración web... enloquecida. Está llena de datos sobre esa petición, como la petición y la respuesta, todos los mensajes de registro que se produjeron durante esa petición, información sobre las rutas y la ruta a la que se respondió, Twig te muestra qué plantillas se renderizaron y cuántas veces se renderizaron... y hay información de configuración aquí abajo. ¡Uf!
Pero mi sección favorita es la de Rendimiento. Muestra una línea de tiempo de todo lo que ha ocurrido durante la petición. Esto es genial por dos razones. La primera es bastante obvia: puedes usarla para encontrar qué partes de tu página son lentas. Así, por ejemplo, nuestro controlador tardó 20,4 milisegundos. Y dentro de la ejecución del controlador, la plantilla de la página de inicio se renderizó en 3,9 milisegundos y base.html.twigse renderizó en 2,8 milisegundos.
La segunda razón por la que esto es realmente genial es que descubre todas las capas ocultas de Symfony. Ajusta este umbral a cero. Antes, esto sólo mostraba las cosas que tardaban más de un milisegundo. Ahora lo muestra todo. No tienes que preocuparte por la gran mayoría de las cosas, pero es superguay ver las capas de Symfony: las cosas que ocurren antes y después de que se ejecute tu controlador. Tenemos un tutorial de inmersión profunda para Symfony si quieres aprender más sobre estas cosas.
La barra de herramientas de depuración web y el perfilador también crecerán con nuestra aplicación. En un futuro tutorial, cuando instalemos una librería para hablar con la base de datos, de repente tendremos una nueva sección que enumera todas las consultas a la base de datos que hizo una página y el tiempo que tardó cada una.
Bien, el paquete de depuración instaló la barra de herramientas de depuración web. También ha instalado una biblioteca de registro que utilizaremos más adelante. Y ha instalado un paquete que nos proporciona dos fantásticas funciones de depuración.
Dirígete a VinylController. Imagina que estamos haciendo un desarrollo y necesitamos ver cómo es esta variable $tracks. En este caso es bastante obvio, pero a veces querrás ver lo que hay dentro de un objeto complejo.
Para ello, digamos dd($tracks), donde "dd" significa "dump" y "die".
| ... lines 1 - 9 | |
| class VinylController extends AbstractController | |
| { | |
| ('/') | |
| public function homepage(): Response | |
| { | |
| ... lines 15 - 22 | |
| dd($tracks); | |
| ... lines 24 - 28 | |
| } | |
| ... lines 30 - 43 | |
| } |
Así que si refrescamos... ¡sí! Eso vuelca la variable y mata la página. Y esto es mucho más potente -y más bonito- que usar var_dump(): podemos ampliar secciones y ver datos profundos con mucha facilidad.
En lugar de dd(), también puedes utilizar dump().. para volcar y vivir. Pero esto podría no aparecer donde esperas. En lugar de imprimirse en el centro de la página, aparece abajo en la barra de herramientas de depuración de la web, bajo el icono del objetivo.
| ... lines 1 - 9 | |
| class VinylController extends AbstractController | |
| { | |
| ('/') | |
| public function homepage(): Response | |
| { | |
| ... lines 15 - 22 | |
| dump($tracks); | |
| ... lines 24 - 28 | |
| } | |
| ... lines 30 - 43 | |
| } |
Si es demasiado pequeño, haz clic para ver una versión más grande en el perfilador.
También puedes utilizar este dump() en Twig. Elimina el volcado del controlador... y luego en la plantilla, justo antes del ul, dump(tracks).
| ... lines 1 - 9 | |
| <div> | |
| Tracks: | |
| {{ dump(tracks) }} | |
| ... lines 14 - 20 | |
| </div> | |
| ... lines 22 - 23 |
Y esto... se ve exactamente igual. Excepto que cuando haces el volcado en Twig, sí que se vuelca justo en el centro de la página
Y aún más útil, sólo en Twig, puedes utilizar dump() sin argumentos.
| ... lines 1 - 9 | |
| <div> | |
| Tracks: | |
| {{ dump() }} | |
| ... lines 14 - 20 | |
| </div> | |
| ... lines 22 - 23 |
Esto volcará todas las variables a las que tengamos acceso. Así que aquí está la variable title,tracks y, ¡sorpresa! Hay una tercera variable llamada app. Es una variable global que tenemos en todas las plantillas... y nos da acceso a cosas como la sesión y los datos del usuario. Y... ¡lo hemos descubierto por curiosidad!
Así que ahora que tenemos estas increíbles herramientas de depuración, pasemos a nuestro siguiente trabajo... que es hacer este sitio menos feo. ¡Es hora de añadir CSS y un diseño adecuado para dar vida a nuestro sitio!
Hey Webcommenterdude,
Sorry if this video was boring for you because of long explaining of the installation process. Unfortunately, that is something we have to cover so other users do not get lost in it. Though, even in this short video we covered some new installed features like Symfony Web Debug Toolbar and VarDumper component. I bet the further chapters would be more interesting for you ;)
P.S. Keep in mind that this is the intro course into the Symfony 6 and is mostly designed for beginners. Yeah, if you already know Symfony and works with it - I agree, it might be less interesting for you... but you can rewind some known for you parts :)
Anyway, thank you for your feedback! We will definitely consider this in our future tutorials and try to spend less time on explaining simple things like the packs and recipes. We just wanted to cover it well now, and do not focus too much attention on it further in this course... and in further courses as well.
Cheers!
Thanks for the tutorial, I like that you explain recipes and composre in greater detail than in the tutorial for Symfony 5, where it was more like magic when the debug tool was installed. (It still is magical though 🪄)
Hey @Brentspine
Thanks for your feedback, and yes, recipes feel like magic, but it is good magic, they save so much time adding configuration
Cheers!
Krystian-S
| posted hace 1 mes
Hi, I have problem. When i try install debug by "composer require debug" i receive:
In FileLoader.php line 172:
Container extension "debug" is not registered in C:\Users\surow\Symfony Projects\mixed_vinyl\config/packages/debug.yaml (which is being imported fr
om "C:\Users\surow\Symfony Projects\mixed_vinyl\src\Kernel.php").
In ContainerBuilder.php line 214:
Container extension "debug" is not registered.
Please, help.
Hey @Krystian-S
Do you already have a config/packages/debug.yaml file but the library it's not installed yet? Try removing the config file, and clear the cache manually just in case rm -r var/cache
Cheers!
Benanamen
| posted hace 5 meses
One issue I had was the debug bar kept trying to load and would not. A .htaccess is required in the public directory for it to work.
` <IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>`
Hey Benanamen,
Thank you for sharing it. If you install the library symfony/apache-pack it will generate the .htaccess for you. You can read more about how to configure a web server for a Symfony app https://symfony.com/doc/current/setup/web_server_configuration.html
Cheers
therouv
| posted hace 9 meses
Followed the steps exactly and yet the toolbar does not appear on any of my browsers.
I've restarted the server, reinstalled the debug-bundle, made sure web_profiler.toolbar is set to true and that APP_ENV=dev... and still nothing.
What is wrong?
The /_profiler/ path works on the browser, but the toolbar is not appearing anywhere.
Hey Therouv,
Hm, did you make sure that the recipe for that package was executed? Sometimes you should allow executing it manually, but sometimes you. may allow it in your composer.json file. Though it might be forbidden in your composer.json and so no recipe was installed. Though, /_profile/ path works for you - I'd guess that the recipe was installed, but would be good to double check anyway. You can remove and install. the package again and look closer to the composer's output - it should have some recipe executed there.
Also, the very important requirement for the WDT to appear is that you should have <body> tag rendered on the page where you want to see it. Please, make sure you have a valid HTML markup on that page, especially the base html/head/body tags and that there are no any misprints or missing closing tags or brackets or quotes. I bet the invalid HTML syntax on that page prevents that WDT to show for you.
Also, try to clear the cache, i'd recommend you to remove the cache dir manually with rm -rf just in case. Sometimes it might be just. a simple cache problem.
I hope this helps!
Cheers!
Also, the very important requirement for the WDT to appear is that you should have <body> tag rendered on the page where you want to see it. Please, make sure you have a valid HTML markup on that page, especially the base html/head/body tags and that there are no any misprints or missing closing tags or brackets or quotes. I bet the invalid HTML syntax on that page prevents that WDT to show for you.
That was it! I forgot to extend the block from base.html.twig. It works now.
Thank you!
Hey Therouv,
Ah, yeah, I got this problem as well before ;) Glad to hear we found the problem :) And thanks for confirming the root of the problem!
Cheers!
// composer.json
{
"require": {
"php": ">=8.0.2",
"ext-ctype": "*",
"ext-iconv": "*",
"symfony/asset": "6.0.*", // v6.0.3
"symfony/console": "6.0.*", // v6.0.3
"symfony/dotenv": "6.0.*", // v6.0.3
"symfony/flex": "^2", // v2.1.5
"symfony/framework-bundle": "6.0.*", // v6.0.4
"symfony/monolog-bundle": "^3.0", // v3.7.1
"symfony/runtime": "6.0.*", // v6.0.3
"symfony/twig-bundle": "6.0.*", // v6.0.3
"symfony/ux-turbo": "^2.0", // v2.0.1
"symfony/webpack-encore-bundle": "^1.13", // v1.13.2
"symfony/yaml": "6.0.*", // v6.0.3
"twig/extra-bundle": "^2.12|^3.0", // v3.3.8
"twig/twig": "^2.12|^3.0" // v3.3.8
},
"require-dev": {
"symfony/debug-bundle": "6.0.*", // v6.0.3
"symfony/stopwatch": "6.0.*", // v6.0.3
"symfony/web-profiler-bundle": "6.0.*" // v6.0.3
}
}
A lot of time wasting on packs and recipes. Get to the point.