Chapters
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Symfony presume de tener algunas de las herramientas de depuración más épicas de todo Internet. Pero como las aplicaciones Symfony empiezan tan pequeñas, aún no las tenemos instaladas. Es hora de arreglarlo. Dirígete a tu terminal y, como antes, confirma todos tus cambios para que podamos comprobar lo que harán las recetas. Ya lo he hecho.
Instalar las herramientas de depuración
Ejecuta:
composer require debug
¡Sí! Es otro alias de Flex. E... instala un paquete. Esto instala cuatro paquetes diferentes que añaden una variedad de bondades de depuración a nuestro proyecto. Gira y abre composer.json
.
{ | |
Show Lines
|
// ... lines 2 - 5 |
"require": { | |
Show Lines
|
// ... lines 7 - 14 |
"symfony/monolog-bundle": "^3.0", | |
Show Lines
|
// ... lines 16 - 20 |
}, | |
Show Lines
|
// ... lines 22 - 78 |
} |
Vale, el paquete ha añadido una nueva línea bajo la clave require
para monolog-bundle
. Monolog es una biblioteca de registro.
Luego, al final, ha añadido tres paquetes a la sección require-dev
.
{ | |
Show Lines
|
// ... lines 2 - 73 |
"require-dev": { | |
"symfony/debug-bundle": "7.0.*", | |
"symfony/stopwatch": "7.0.*", | |
"symfony/web-profiler-bundle": "7.0.*" | |
} | |
} |
Se conocen como dependencias de desarrollo... lo que significa que no se descargarán cuando los despliegues en producción. Por lo demás, funcionan igual que los paquetes de la clave require
. Los tres ayudan a impulsar algo llamado perfilador, que veremos dentro de un minuto.
Antes de hacerlo, vuelve a tu terminal y ejecuta
git status
para que podamos ver lo que hicieron las recetas. Vale: actualizó los archivos normales, habilitó unos cuantos bundles nuevos y nos dio tres archivos de configuración nuevos para esos bundles.
¿Cuál es el resultado final de todo esto nuevo? Bueno, en primer lugar, ahora tenemos una biblioteca de registros. Así que, como por arte de magia, los registros empezarán a aparecer en un directorio var/log/
.
Hola barra de herramientas de depuración web y perfilador
Pero el momento alucinante ocurre cuando actualizamos la página. ¡Woh! Una nueva y hermosa barra negra en la parte inferior llamada barra de herramientas de depuración web.
Está repleta de información. Aquí podemos ver la ruta y el controlador de esta página. Eso facilita ir a cualquier página de tu sitio -quizá una que ni siquiera hayas construido- y encontrar rápidamente el código que hay detrás. También podemos ver cuánto tardó en cargarse esta página, cuánta memoria utilizó, e incluso la plantilla Twig que se renderizó y cuánto tardó.
Pero la verdadera magia de la barra de herramientas de depuración web ocurre cuando haces clic en cualquiera de estos enlaces: saltas al perfilador. Éste tiene diez veces más información: detalles sobre la petición y la respuesta, registros que se produjeron mientras se cargaba la página, detalles de enrutamiento e incluso estadísticas sobre las plantillas Twig que se procesaron. Aparentemente, se estaban renderizando seis plantillas: la principal, el diseño base y algunas otras que alimentan la barra de herramientas de depuración web, que, por cierto, no se renderizarán ni se mostrarán cuando pasemos a producción. Pero de eso hablaremos en el próximo tutorial.
Luego está probablemente mi sección favorita: Rendimiento. Aquí se divide todo el tiempo de carga de nuestra página en diferentes partes. Esto me encanta. A medida que aprendas más sobre Symfony, te irás familiarizando con lo que son estas diferentes piezas. Esta sección es útil para saber qué parte de tu código puede estar ralentizando la página... pero también es una forma fantástica de profundizar en Symfony y entender todas sus piezas móviles.
Vamos a utilizar el perfilador a lo largo de esta serie, pero pasemos a otra herramienta de depuración: ¡una que ha estado instalada en nuestra aplicación todo este tiempo!
¡Hola bin/console!
Dirígete a la línea de comandos y ejecuta:
php bin/console
O, en la mayoría de las máquinas, puedes decir simplemente ./bin/console
. Esta es la consola de Symfony, y está repleta de comandos que pueden hacer todo tipo de cosas Aprenderemos sobre ellos a lo largo del camino. También puedes añadir tus propios comandos, cosa que haremos al final del tutorial.
Fíjate en que muchos de ellos empiezan por debug
, como debug:router
. Pruébalo:
php bin/console debug:router
¡Genial! Esto nos muestra todas las rutas de nuestra aplicación: la ruta de la página de inicio en la parte inferior y un montón de rutas añadidas por Symfony en el entorno dev
que alimentan la barra de herramientas de depuración web y el perfilador.
Otro comando es debug:twig
:
php bin/console debug:twig
Nos indica todas las funciones, filtros u otros elementos de Twig que existen en nuestra aplicación. Es como la documentación de Twig... salvo que también incluye funciones y filtros adicionales añadidos a Twig por los bundles que hemos instalado. Genial.
Estos comandos de debug
son superútiles, y seguiremos probando más de ellos por el camino.
A continuación, vamos a crear nuestra primera ruta API y a conocer el potente componente serializador de Symfony.
25 Comments
Hey @pasquale_pellicani ,
Thanks for this tip! Indeed, if you're using Apache instead of built-in Symfony web server that we're using in the screencast - you would need that symfony/apache-pack
package that will bring an .htaccess
file into your app.
Cheers!
Could you also please explain how to remove bundles or packs?
Hey @tomoguchi ,
How to remove? It's as easy as execute composer remove
command. If you use Symfony Flex - it will also remove config files. If no, you will need to do it manually. But basically, you just need to drop the package from your composer.json file, for this you leverage the command I mentioned above: composer remove ...
and then you need to disable the bundle in the config/bundles.php
- just literally drop the related namespace from there. Then clean up any related config files in the config/
dir. I think that's all :)
Cheers!
hello @Victor does that also removes the generated files, setting and autowirings composer require some-bundle
created?
Hey @tomoguchi ,
Yes, it has to remove those files too. Well, not the files you created manually but the files that were created by Symfony Flex recipe. But it will happen only if you have Symfony Flex enabled and allowed in your project.
Cheers!
adding this inside controller method:
$x = '1';
$y = '2';
dump($x);
dump($y);
each use of dump() is adding 2 seconds to execution time. So this takes 4seconds to load the script.
I intend to use it quite a lot to track things down is there a way to make it quicker ?
Hey @John-S, this is indeed odd. To confirm, removing one dump()
reduces the request time to ~2 seconds and adding a dump()
increases to ~6 seconds? Do you see the dump output as expected in the profiler?
1 dump() 2 seconds.
2 dump() 4 seconds.
3 uses of dump() profiler line:
dump 6078.2 ms / 2 MiB
probably something with the settings but just not sure what.
Does it happen on every request? In particular when you don't change the code
Do you experiment the same behavior with a different Symfony app?
I believe you may have added by mistake a sleep()
somewhere in your vendors. Try re-installing them
Cheers!
Is it ok that dump() increases every request time to 2seconds?
I haven't installed the monolog bundle but installed symfony/stopwatch --dev. I have short array on my controller and using dump($simpleArray) on it. It now it takes 2seconds to load every request (dump 2037.7 ms / 2 MiB). Is this ok ?
Hey John,
It depends on the data you're trying to dump. If you're dumping heavy objects, the serialization may really take long time. Also, sometimes it depends if you're using a virtualization tool like Docker or no. With virtualization tools numbers can be really much more increased.
But in short, that's OK, because you should use dump()
/dd()
features only in dev mode and never should use it on production.
Cheers!
hello,
I'm having a hard time following which packages require "--dev" addon.
For example I see both the symfony/debug-bundle on docs and on packagist website recommended installation as "composer require symfony/debug-bundle" but here(composer.json) is under require-dev. My installation settled it under "require".
how to do it right ?
p.s. I know this is introductory tutorial but i really try to install all features individually and not packs so I can keep the track on and know what's what.
Hey @John-S
To make composer install things under the require-dev
key, you need to pass the --dev
flag. You can also manually move the dependencies from one key to another in case you forgot to add the flag.
Cheers!
Hello,
Could you please show how to remove debug from the bar? I did composer remove debug. but still I see the debug bar.
thank you
Hey @Mahmut-A
Can I ask why? You're the first one I know who doesn't like it - lol
Seriously, that debug toolbar is only loaded on the "dev" environment. You can remove it by deleting the bundle's entry in config/bundles.php
Cheers!
Hi,
the first reason is actually I wanted to test to remove a package from composer. so when I used composer remove command, composer.json did not delete this package. so I did not want to wrong thing to affect all symfony environment.
the second reason, I am building my project in web service apache. so I do not want show the debug to clients.
then, I understand that if any package is need to remove, I need to remove from config/bundle.php right?
thank you for your help
Ok, the bundle you want to remove is this one symfony/debug-bundle
- I recommend not removing it because it only works on the "dev" environment, so your clients won't see it, also, it should be in the require-dev
composer key and those dependencies should not be installed in your production server. You can do that by adding the flag composer install --no-dev
then, I understand that if any package is need to remove, I need to remove from config/bundle.php right?
That's true only for bundles
Cheers!
Hi MolloKhan,
Thank you.
I applied this command: composer install --no-dev but page gives below error:
Attempted to load class "DebugBundle" from namespace "Symfony\Bundle\DebugBundle".<br />Did you forget a "use" statement for another namespace?
because of that, ı added debug again by command composer require debug
When installing composer deps using the --no-dev
flag your must run your application on the "prod" environment, otherwise it will try to load dev dependencies but those were not installed, hence, your error
Actually, how can we describe prod? Because my project under /var/www/html and it is working as a apache web.
I dont do in localhost.
Because of that, my expectation is when I do this —no-dev command, it should be disabled.
Thank you so much again for your kindly help
I mean the APP_ENV
environment variable. That should be set to "prod" - I recommend you to watch this video, it will give you a better idea of Symfony environments https://symfonycasts.com/screencast/symfony-fundamentals/environments
Cheers!
"Houston: no signs of life"
Start the conversation!
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": ">=8.2",
"ext-ctype": "*",
"ext-iconv": "*",
"php-cs-fixer/shim": "^3.46", // v3.46.0
"phpdocumentor/reflection-docblock": "^5.3", // 5.3.0
"phpstan/phpdoc-parser": "^1.25", // 1.25.0
"symfony/asset": "7.0.*", // v7.0.3
"symfony/asset-mapper": "7.0.*", // v7.0.2
"symfony/console": "7.0.*", // v7.0.2
"symfony/dotenv": "7.0.*", // v7.0.2
"symfony/flex": "^2", // v2.4.3
"symfony/framework-bundle": "7.0.*", // v7.0.2
"symfony/monolog-bundle": "^3.0", // v3.10.0
"symfony/property-access": "7.0.*", // v7.0.0
"symfony/property-info": "7.0.*", // v7.0.0
"symfony/runtime": "7.0.*", // v7.0.0
"symfony/serializer": "7.0.*", // v7.0.2
"symfony/stimulus-bundle": "^2.13", // v2.13.3
"symfony/twig-bundle": "7.0.*", // v7.0.0
"symfony/ux-turbo": "^2.13", // v2.13.2
"symfony/yaml": "7.0.*", // v7.0.0
"symfonycasts/tailwind-bundle": "^0.5.0", // v0.5.0
"twig/extra-bundle": "^2.12|^3.0", // v3.8.0
"twig/twig": "^2.12|^3.0" // v3.8.0
},
"require-dev": {
"symfony/debug-bundle": "7.0.*", // v7.0.0
"symfony/maker-bundle": "^1.52", // v1.53.0
"symfony/stopwatch": "7.0.*", // v7.0.0
"symfony/web-profiler-bundle": "7.0.*" // v7.0.2
}
}
I add a suggestion that can avoid wasting an hour of attempts to make the call to the _wdt route work!
install this, after composer require debug command:
composer require symfony/apache-pack