If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeNuestra aplicación se está ejecutando actualmente en el entorno dev
. Cambiémosla a prod
... que es el que usarías en producción. Cambia temporalmente APP_ENV=dev
porprod
... y luego dirígete a él y actualízalo. ¡Vaya! La barra de herramientas de depuración web ha desaparecido. ¡Eso... tiene sentido! Todo el bundle del perfilador web no está activado en el entorno prod
.
También observarás que el volcado de nuestro controlador aparece en la parte superior de la página. El perfilador web normalmente captura eso y lo muestra abajo en la barra de herramientas de depuración web. Pero... como todo ese sistema ya no está habilitado, ahora hace el volcado justo donde lo llamas.
Y hay muchas otras diferencias, como el registrador, que ahora se comporta de forma diferente gracias a la configuración en monolog.yaml
.
La forma de construir las páginas también ha cambiado. Por ejemplo, Symfony almacena en caché muchos archivos... pero eso no se nota en el entorno dev
. Eso es porque Symfony es súper inteligente y reconstruye esa caché automáticamente cuando cambiamos ciertos archivos. Sin embargo, en el entorno prod
, eso no ocurre.
¡Compruébalo! Abre templates/base.html.twig
... y cambia el título de la página a Stirred Vinyl
. Si vuelves y actualizas... ¡mira aquí! No hay cambios! Las propias plantillas Twig se almacenan en la caché. En el entorno dev
, Symfony reconstruye esa caché por nosotros. ¿Pero en el entorno prod
? No Tenemos que borrarla manualmente.
¿Cómo? En tu terminal, ejecuta:
php bin/console cache:clear
Fíjate que dice que está borrando la caché del entorno prod. Así, al igual que nuestra aplicación se ejecuta siempre en un entorno concreto, los comandos de la consola también se ejecutan en un entorno concreto. Y lee la misma bandera APP_ENV
. Así que, como tenemos aquí APP_ENV=prod
, cache:clear
sabe que debe ejecutarse en el entorno prod y borra la caché para ese entorno.
Gracias a esto, cuando refrescamos... ahora el título se actualiza. Volveré a cambiar esto por nuestro nombre genial, Mixed Vinyl
.
¡Vamos a probar otra cosa! Abre config/packages/cache.yaml
. Nuestro servicio de caché utiliza actualmente el ArrayAdapter
, que es una caché falsa. Eso puede estar bien para el desarrollo, pero no será de mucha ayuda en producción.
Veamos si podemos volver a cambiar al adaptador del sistema de archivos, pero sólo para el entornoprod
. ¿Cómo? Aquí abajo, usa when@prod
y luego repite las mismas claves. Así que framework
, cache
, y luego app
. Pon esto en el adaptador que queremos, que se llama cache.adapter.filesystem
.
Va a ser muy fácil ver si esto funciona porque seguimos volcando el servicio de caché en nuestro controlador. Ahora mismo, es un ArrayAdapter
. Si refrescamos... ¡sorpresa! Sigue siendo un ArrayAdapter
. ¿Por qué? Porque estamos en el entorno de producción... y prácticamente cada vez que haces un cambio en el entorno prod
, tienes que reconstruir tu caché.
Vuelve a tu terminal y ejecuta
php bin console cache:clear
de nuevo y ahora... lo tienes - ¡ FilesystemAdapter
!
Pero... vamos a invertir esta configuración. Copia cache.adapter.array
y cámbialo porfilesystem
. Lo usaremos por defecto. Luego, en la parte inferior, cambia a when@dev
, y esto a cache.adapter.array
.
¿Por qué hago esto? Bueno, esto literalmente no supone ninguna diferencia en los entornos dev
yprod
. Pero si decidimos empezar a escribir pruebas más adelante, que se ejecuten en el entorno de pruebas, con esta nueva configuración, el entorno de pruebas utilizará el mismo servicio de caché que el de producción... lo que probablemente sea más realista y mejor para las pruebas.
Para asegurarte de que esto sigue funcionando, borra la caché una vez más. Refresca y... ¡funciona! Seguimos teniendo FilesystemAdapter
. Y... si volvemos al entorno dev
en .env
... y refrescamos... ¡sí! La barra de herramientas de depuración de la web ha vuelto, y aquí abajo, ¡volvemos a utilizar ArrayAdapter
!
Ahora bien, en realidad, es probable que nunca cambies al entorno prod
mientras estés desarrollando localmente. Es difícil trabajar con él... ¡y no tiene sentido! ¡El entorno prod
está realmente pensado para producción! Y así, ejecutarás ese comando bin/console cache:clear
durante el despliegue... pero probablemente casi nunca en tu máquina local.
Antes de continuar, entra en VinylController
, baja a browse()
, y saca ese dump()
.
Bien, ¡comprobación de estado! Primero, todo en Symfony lo hace un servicio. Segundo, los bundles nos dan servicios. Y tercero, podemos controlar cómo se instancian esos servicios a través de las diferentes configuraciones de bundle en config/packages/
.
Ahora, vamos a dar un paso importante creando nuestro propio servicio.
Hey @Domingo987
That's odd. From the error, I believe you're not loading the TwigBundle
for the prod environment. Check your bundles.php
file to see if it loads that bundle. Also, I may recommend to re-install your vendor directory
Let me know if that helped. Cheers!
Thanks for suggestions but nothing will work. I've done a composer update, I've checked the bundles, cleared the caches.
I work with Symfony since Symfony 4. Its the first time that the prod environement will not work as the dev.
I put here the log :
[PHP-FPM ] {"message":"Authenticator does not support the request.","context":{"firewall_name":"main","authenticator":"App\\Security\\UtilisateurAuthenticator"},"level":100,"level_name":"DEBUG","channel":"security","datetime":"2023-05-09T08:00:22.966375+00:00","extra":{}}
[PHP-FPM ] {"message":"Uncaught PHP Exception Twig\\Error\\SyntaxError: \"Did you forget to run \"composer require symfony/twig-bundle\"? Unknown function \"dump\" in \"actualites/actu_detail.html.twig\".\" at /Users/symfony6/town/vendor/symfony/twig-bridge/UndefinedCallableHandler.php line 93","context":{"exception":{"class":"Twig\\Error\\SyntaxError","message":"Did you forget to run \"composer require symfony/twig-bundle\"? Unknown function \"dump\" in \"actualites/actu_detail.html.twig\".","code":0,"file":"/Users/Sites/symfony6/town/vendor/symfony/twig-bridge/UndefinedCallableHandler.php:93"}},"level":500,"level_name":"CRITICAL","channel":"request","datetime":"2023-05-09T08:00:23.532817+00:00","extra":{}}
[Web Server ] May 9 10:00:23 |ERROR | SERVER GET (500) /actualite/first-time ip="127.0.0.1"
Thanks for any suggestions
Interesting... Have you checked your config and service files for some weird, prod-specific config? If that's not the case I believe the error message is misleading. Try disabling xDebug, it sometimes causes a weird behavior
I am an "end user". I have started a new project from scratch. For the moment the dev and the prod work both well.
Thanks for your help.
Hi team,
I'm absolutly disappointed. Since 2 dys I try to install py project on a server (Website). I respect all in how to deploy, and no css, js... . I use webpack encore and commands "yarn encore production" & "yarn build run" works fine in my computer. Have you an idea? (I clear cache php bin/console cache:clear --env=prod and delete folder "cache" before sftp transfert)
Thank' in advance
For completed I note that webpack doesn't point in the good directory : in console error it search build directory at the root, and in reality it could be find in public directory. How solve this? To solve this for the moment I make a copy of build in root directory. It works but it's not the solution. I have no subsdirectory.
Many thanks
Hi @Delenclos-A!
I'm absolutly disappointed.
Well, we don't want that. So let me see if I can help :). And yes, I think I can see the problem! We CAN solve this problem with a tweak in your Webpack config. But actually, I can suggest a (hopefully) better solution overall for you.
Ok, so the site is installed at http://potcommun.lamih.fr/public/login
. The key thing I notice is that the public
directory is in the URL. Even ignoring Webpack, that isn't ideal. I'm guessing it would be much nicer to just have the URL be http://potcommun.lamih.fr/login
. This would also fix the Webpack problem.
On your host, you probably have a document root directory which is available to the public - let's pretend it is /var/www
. And so, you've deployed your app into this directory. This means you have a /var/www/public
directory with your application's index.php
inside of it. That's why you need to have the extra /public
in the URL: that executes the /var/www/public/index.php
file.
To remove the extra public, you have 2 options:
1) If you have access to your server configuration (e.g. Apache, Nginx, etc) and are able to, you could change the "document root" from /var/www/
to /var/www/public
. This is really the only directory that should be public (right now, your entire project source is public - e.g. https://potcommun.lamih.fr/webpack.config.js
2) Or, an often easier way is to use a symbolic link. That looks like this:
A) Deploy your app to some OTHER directory that is NOT served by your web server - e.g. ~/potcommun
.
B) Delete the web root - so literally rm -rf /var/www
C) Create a symbolic link from /var/www
to /potcommun/public
. The command is:
cd /var
ln -s ~/potcommun/public www
With this setup, your document root will STILL be /var/www
. But that is a symbolic link to the public/
directory of your app.
Please let me know if this helps!
Hi, great answer. Thank's to take time to help symfony's community. It works fine. I've changed the document root and it's just magic.
Have a good day and Thank's
In my environment, switching to prod does not show any dump on top of the page as in your video
Hey @Anatolie
I'm guessing you forgot to clear the cache for the prod environment. Could you double-check that?
Cheers!
When I just switch to 'prod', I get a 500 error, turns out I need to clear cache first before switching to 'prod', the steps are:
php bin/console cache:clear
.env
file to switch to 'prod'Hey @Yulong!
Hmm. I'm not sure what happened in your situation, but normally you would need to switch steps 1 and 2. The idea is:
1) Edit .env
file to switch to prod
(at this point, if you refreshed, you WILL likely get a 500 error).
2) php bin/console cache:clear
- because .env
is set to prod
this will clear the prod
cache. If you did this step before step 1, it would be clearing the dev
cache, which is something you can do, but it wouldn't help in the prod
environment.
Anyways, I'm sure it was something minor - I just wanted to give you a bit more detail about the "why" behind the order of these steps. Btw, you can also run php bin/console cache:clear --env=prod
to clear the "prod" cache, regardless of what APP_ENV
is set to in .env
:).
Cheers!
// composer.json
{
"require": {
"php": ">=8.1",
"ext-ctype": "*",
"ext-iconv": "*",
"knplabs/knp-time-bundle": "^1.18", // v1.19.0
"symfony/asset": "6.1.*", // v6.1.0-RC1
"symfony/console": "6.1.*", // v6.1.0-RC1
"symfony/dotenv": "6.1.*", // v6.1.0-RC1
"symfony/flex": "^2", // v2.1.8
"symfony/framework-bundle": "6.1.*", // v6.1.0-RC1
"symfony/http-client": "6.1.*", // v6.1.0-RC1
"symfony/monolog-bundle": "^3.0", // v3.8.0
"symfony/runtime": "6.1.*", // v6.1.0-RC1
"symfony/twig-bundle": "6.1.*", // v6.1.0-RC1
"symfony/ux-turbo": "^2.0", // v2.1.1
"symfony/webpack-encore-bundle": "^1.13", // v1.14.1
"symfony/yaml": "6.1.*", // v6.1.0-RC1
"twig/extra-bundle": "^2.12|^3.0", // v3.4.0
"twig/twig": "^2.12|^3.0" // v3.4.0
},
"require-dev": {
"symfony/debug-bundle": "6.1.*", // v6.1.0-RC1
"symfony/maker-bundle": "^1.41", // v1.42.0
"symfony/stopwatch": "6.1.*", // v6.1.0-RC1
"symfony/web-profiler-bundle": "6.1.*" // v6.1.0-RC1
}
}
Hello,
I have developed an app in 6.2 which works perfectly in dev, but when i swith to prod it will not work anymore. I've cleared the caches but this doesn't change the issue.
The log talks about "Authenticator does not support the request." and "Did you forget to run \"composer require symfony/twig-bundle\"? As I said: in dev-mode the app works perfectly.
Any ideas ? Thanks