Chapters

13 Chapters | 1:09:47 |

01

Actualización a Symfony 6.4

7:01
02

Actualizaciones de recetas Flex

6:04
03

Encore, StimulusBundle y sus cambios de recetas

8:07
04

Adiós a SensioFrameworkExtraBundle

2:50
05

Encontrar y eliminar depreciaciones

6:16
06

Actualización a Symfony 7

5:05
07

Migrando Encore -> AssetMapper

3:31
08

Encore -> AssetMapper Parte 2

8:40
09

Modernizar con fetch() y await

2:37
10

Nuevos atributos de autocableado

4:30
11

MapQueryParameter y carga útil de la petición

4:36
12

Comandos de perfilado

2:35
13

Nuevo Componente: Programador

7:55

> Symfony 7 > Actualizar y qué hay en Symfony 7

Buy Access to Course

05.

Encontrar y eliminar depreciaciones

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $10.00

Previous Chapter

Next Chapter

With a Subscription, click any sentence in the script to jump to that part of the video!

El sistema de desaprobación de Symfony es un unicornio en Internet: no conozco nada que lo iguale. Es una de las cosas que hacen a Symfony tan especial y en la que se invierte mucho trabajo

Cómo Symfony cambia / desaprueba funciones

Supongamos que en Symfony queremos cambiar algo: como el nombre de un método. No podemos simplemente cambiar el nombre del método, porque eso rompería tu código. En lugar de eso, añadimos el nuevo nombre del método, mantenemos el antiguo, pero añadimos una pequeña función de código de desaprobación en ese método antiguo. Lanzamos eso en una versión menor, como la 6.3 o la 6.4. Entonces, actualizas a esa versión y, como tu código está llamando al método antiguo, se encuentra con esa desaprobación, lo que desencadena una advertencia de desaprobación. Estas advertencias se recopilan, y podemos verlas de varias formas, como en la Barra de Herramientas de Depuración Web.

Tu trabajo consiste en leerlos y actualizar tu código para llamar al nuevo nombre de método. Una vez que hayan desaparecido todas las desaprobaciones, puedes actualizarte a Symfony 7.0 sin problemas. Porque, recuerda, la única diferencia entre Symfony 6.4 y Symfony 7.0 es que las rutas de código obsoletas han desaparecido. En nuestro ejemplo, significa que el antiguo nombre del método se elimina definitivamente en 7.0.

Me encanta este proceso. Significa que Symfony puede cambiar cosas y seguir modernizándose, y nosotros podemos actualizar nuestras aplicaciones de forma segura y predecible. Es lo mejor.

A la caza de las desapropiaciones

Así que hoy, somos detectives de desaprobaciones: en una misión para cazarlas y eliminarlas. Para empezar, borraré manualmente mi directorio de caché

rm -rf var/cache/*

para que cuando vayamos y actualicemos la página de inicio, se cree la caché. Algunas advertencias de desaprobación sólo se producen mientras se construye la caché. Vale, parece que nos quedan tres advertencias después de actualizar nuestras recetas. ¡Qué bien!

Eliminar symfony/templating

Ábrelos. La primera está relacionada con una clase de ayuda para plantillas que está obsoleta. No es algo que recuerde haber usado en mi código. Mira la traza. No es muy útil. Aquí está la clase de ayuda... llamada por un cargador de clases.

Esto me dice que algo está intentando utilizar esta clase... y la clase está totalmente obsoleta. De hecho, todo este componente symfony/templating está obsoleto: ¡no existe en absoluto en Symfony 7.0! De todas formas, es muy probable que nunca lo hayas utilizado... y yo no lo voy a utilizar en mi aplicación. Entonces, ¿quién la utiliza?

Para averiguarlo, ve a la línea de comandos y ejecuta:

composer why symfony/templating

Esto lo necesita knplabs/knp-time-bundle. Haz clic en el enlace para saltar a nuestra versión instalada: 1.20.0. Pero esa no es la última versión: ahora tiene una versión 2.2. ¡Vamos muy retrasados! La versión mayor 2.0 moderniza el código... y es muy probable que eso haya incluido la eliminación de la dependencia de plantillas. De hecho, lo vemos aquí abajo.

Se trata de una nueva versión mayor del paquete, por lo que debemos consultar el registro de cambios o las notas de la versión para comprobar si hay alguna interrupción de la compatibilidad con versiones anteriores que pueda afectarnos.

Lo interesante de esta primera desaprobación es que... no es algo que hayamos llamado directamente. Es una desaprobación indirecta: causada por una biblioteca que estamos utilizando. Y eso es bastante común. Para estar preparados para Symfony 7, tenemos que actualizar este bundle.

En composer.json, busca "time"... y cámbialo por el más reciente ^2.2. Gira y ejecuta:

composer up

Actualiza el paquete... ¡y elimina symfony/templating!

DoctrineFixturesBundle Falsa Deprecación

Vale, vuelve a borrar la caché, cierra algunas pestañas y vamos a la página "examinar mezclas", porque eso conecta con la base de datos. Esta vez, vemos dos desaprobaciones. Ábrelas y sumérgete en ellas. La primera tiene algo que ver con los data fixtures. Si miramos la traza, no es superobvio, pero procede de DoctrineFixturesBundle. Esto es complicado: He tenido que bucear en el repositorio de GitHub de DoctrineFixturesBundle para encontrar una conversación. Esta vez, ¡la desaprobación es una falsa advertencia! La capa de desaprobación que se añadió al bundle no se hizo correctamente. El mantenedor confirma que está bien... así que cuando actualicemos a Symfony 7, las cosas no se romperán.

Se trata de una situación extraña, pero demuestra que cazar depreciaciones puede ser complicado

Depreciaciones de Doctrine

La última deprecación es más larga y sigue un formato diferente. Hasta ahora, cada mensaje incluía el paquete en el que vivía la deprecación y la versión en la que se deprecaba. Pero aquí no vemos eso. Y, al final, hace referencia a una incidencia del repositorio doctrine/orm.

¡Ah! Esta deprecación no viene de Symfony: ¡viene dedoctrine/orm! Esto nos dice que vamos a tener que hacer un cambio en nuestro código -en algún momento- antes de actualizar a la siguiente versión principal de ese paquete. Hoy sólo estamos centrados en actualizar Symfony, así que ésta también es una deprecación que podemos ignorar.

Así que... sí, creo que estamos bien. Nuestra aplicación es bastante pequeña, pero al hacer clic, las únicas desaprobaciones que veo son las que acabamos de ver.

Registro de desaprobaciones en producción

Pero... ¿cómo podemos estar seguros de que no hay una página que olvidamos comprobar o un envío de formulario que desencadena una depreciación? La respuesta: el registro.

En config/packages/monolog.yaml, en la parte inferior, tenemos la configuración del registro de producción. El gestor principal es el gestor nested: éste registra los errores en producción. Los registra en stderr, o puedes cambiarlo a un archivo.

            
Copy Code

Show All Lines

                        63 lines
            |
            config/packages/monolog.yaml
        
Show Lines

                                                    // ... lines 1 - 39
                            
            when@prod:
        
                monolog:
        
                    handlers:
        
Show Lines

                                                    // ... lines 43 - 48
                            
                        nested:
        
                            type: stream
        
                            path: php://stderr
        
                            level: debug
        
                            formatter: monolog.formatter.json
        
Show Lines

                                                    // ... lines 54 - 63

La cuestión es: es de esperar que estés recogiendo los errores de producción en algún sitio. En la parte inferior, hay otro gestor llamado deprecation. Éste registra todos los avisos de desaprobación en el mismo lugar. Así que en tus registros de errores de producción, también deberías ver avisos de desaprobación.

            
Copy Code

Show All Lines

                        63 lines
            |
            config/packages/monolog.yaml
        
Show Lines

                                                    // ... lines 1 - 39
                            
            when@prod:
        
                monolog:
        
                    handlers:
        
Show Lines

                                                    // ... lines 43 - 48
                            
                        nested:
        
                            type: stream
        
                            path: php://stderr
        
                            level: debug
        
                            formatter: monolog.formatter.json
        
Show Lines

                                                    // ... lines 54 - 57
                            
                        deprecation:
        
                            type: stream
        
                            channels: [deprecation]
        
                            path: php://stderr
        
                            formatter: monolog.formatter.json

Así que: arregla todas las imprecisiones que encuentres, despliega en producción, espera un día o dos y comprueba los registros para ver si hay imprecisiones. Una vez que no las haya, puedes pasar a Symfony 7.0. ¡Hagamos esa actualización a continuación!

2 Comments

Sort By

Peter-K 3 days ago edited

Hello, not sure if this belongs here but

I have these 2 deprecations

Since symfony/doctrine-bridge 6.3: Registering "Gedmo\Loggable\LoggableListener" as a Doctrine subscriber is deprecated. Register it as a listener instead, using e.g. the #[AsDoctrineListener] attribute.

User Deprecated: Since symfony/doctrine-bridge 6.3: Registering "Gedmo\Loggable\LoggableListener" as a Doctrine subscriber is deprecated. Register it as a listener instead, using e.g. the #[AsDoctrineListener] or #[AsDocumentListener] attribute.

namespace App\EventSubscriber;


use Gedmo\Loggable\LoggableListener;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface;

class DoctrineExtensionSubscriber implements EventSubscriberInterface
{

    public function __construct(private LoggableListener $loggableListener, private TokenStorageInterface $tokenStorage)
    {
    }

    public static function getSubscribedEvents(): array
    {
        return [
            RequestEvent::class => 'onKernelRequest',

        ];
    }

    public function onKernelRequest()
    {
        if ($this->tokenStorage !== null &&
            $this->tokenStorage->getToken() !== null &&
            $this->tokenStorage->getToken()->getUser() !== null
        ) {
            $this->loggableListener->setUsername($this->tokenStorage->getToken()->getUserIdentifier());
        }
    }

And this works nicely so if I update field it will version it.

This is my service

    Gedmo\Loggable\LoggableListener:
        tags:
            - { name: doctrine.event_subscriber, connection: default }

But I tried many things but none of them work.
I updated doctrine.event_subscriber to listener
Created new listener and was listening for onFlush

like this:

Gedmo\Loggable\LoggableListener:
    tags:
        - { name: doctrine.event_listener, event: 'onFlush', connection: default }

namespace App\EventSubscriber;

use Doctrine\Bundle\DoctrineBundle\Attribute\AsDoctrineListener;
use Doctrine\ORM\Events;
use Gedmo\Loggable\LoggableListener;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface;

#[AsDoctrineListener(event: Events::onFlush, connection: 'default')]
class DoctrineExtensionListener
{
    public function __construct(private LoggableListener $loggableListener, private TokenStorageInterface $tokenStorage)
    {
//        dump($this->tokenStorage); // will output tokenStorage
//        exit;
    }

    public function onFlush(): void
    {
        if ($this->tokenStorage !== null &&
            $this->tokenStorage->getToken() !== null &&
            $this->tokenStorage->getToken()->getUser() !== null
        ) {
            dump($this->tokenStorage->getToken()->getUserIdentifier()); // will output username
            $this->loggableListener->setUsername($this->tokenStorage->getToken()->getUserIdentifier());
        }
    }
}

I managed to get rid of these deprecations but then setting username did not work.

Not sure were I am doing mistake but I just cannot get rid of that message and set username

Sadly I could not find anything on google or in doc.

And this is how Gedmo was changed to attributes from annotations

Entity

#[Gedmo\Versioned]
    #[Groups('appSetting')]
    #[ORM\Column(type: 'string', length: 255)]
    private $name;

doctrine.omr.mappings:
            gedmo_loggable:
                type: attribute
                alias: Gedmo
                prefix: Gedmo\Loggable\Entity
                dir: "%kernel.project_dir%/vendor/gedmo/doctrine-extensions/src/Loggable/Entity"
                is_bundle: false

Can someone point me to right direction and tell me what I am doing wrong

| Reply |

weaverryan SFCASTS Peter-K 3 days ago

Hey @Peter-K!

I don't have answer, but it sounds like Doctrine Bridge made some changes. The Gedmo docs have changed I think, to reflect this: https://github.com/doctrine-extensions/DoctrineExtensions/blob/main/doc/symfony.md#doctrine-extension-listener-services

This converts to a listener, like you did, but I believe when a service is manually registered like this, all of the events, like onFlush need to be in the service definition (the YAML). I think the attribute above the class is ignored.

Let me know if this helps!

Cheers!