Développez votre site web avec le framework Symfony

Remise à niveau de Symfony 2 vers 5

a marqué ce sujet comme résolu.

Je me souviens clairement avoir fait une grosse repasse sur celle-ci, la théorie devrait tenir un peu plus la route.

Par contre, j’apprécierais d’avoir des retours, notamment comme expliqué dans le message du début  ;)

+0 -0

Mes remarques sur la partie "IV 4/Les services, utilisation poussée" :

Petite erreur ici : php bin/console debug:container —tag=twig.extension (et non debug:container)

Il faut remplacer les "setDefaultOptions" par "configureOptions()"

Il faut remplacer les "OptionsResolverInterface" par "OptionsResolver"

Juste après "et d’ajouter le setter correspondant" le début de ma classe est légèrement différent :

namespace App\Service;

use Symfony\Component\Mailer\MailerInterface;
use Twig\Extension\AbstractExtension;
use Twig\TwigFunction;

class Antispam extends AbstractExtension
{
    protected $mailer;
    protected $locale;
    protected $nbForSpam;

     // Dans le constructeur, on retire $locale des arguments
    public function __construct(MailerInterface $mailer, int $nbForSpam)
    {
        $this->mailer    = $mailer;
        $this->nbForSpam = $nbForSpam;
    }
    ...

Autre chose => "N’oubliez pas de supprimer l’argument %locale% "

Pas besoin pour moi il me semble car voici mon services.yaml :

parameters:
    locale: fr 

services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true      # Automatically injects dependencies in your services.
        autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.
        bind:
            $locale: "%locale%"        

    # makes classes in src/ available to be used as services
    # this creates a service per class whose id is the fully-qualified class name
    App\:
        resource: '../src/'
        exclude:
            - '../src/DependencyInjection/'
            - '../src/Entity/'
            - '../src/Kernel.php'
            - '../src/Tests/'
    # add more service definitions when explicit configuration is needed
    # please note that last definitions always *replace* previous ones
    App\Service\Antispam:
        arguments:
            $nbForSpam: 3
        tags: ['twig.extension']

Pour la partie "Les champs d’applications, ou scopes" => maintenant il faut utiliser shared: false si on peut obtenir une nouvelle instance à chaque fois (scope n’est plus accepté).

Pour la partie "Les services courants de Symfony" :

-> security.context n’existe plus. ce service a été déconseillé dans la 2.6 et divisé en deux nouveaux services : -> security.authorization_checker(contient juste la méthode isGranted) : c’est le principal point d’autorisation du composant Sécurité. Il donne accès au jeton représentant l’authentification de l’utilisateur actuel.

    -> security.token_storage : un stockage de jeton qui incrémente l'index d'utilisation de la session lorsque le jeton est accédé.

-> Le service templating n’existe plus : à partir de Symfony 5.0, les templates PHP ne sont plus supportés. On doit utiliser Twig à la place.

Voilà je précise que je suis débutant donc ça ne serait pas étonnant qu’une de mes remarques soit fausse.

Bonne soirée !

+2 -0

Voici mes remarques pour la partie IV/ 5) « Le gestionnaire d’évènements de Symfony » :

1) Il faut remplacer les « $this->get(’event_dispatcher’) » par « $this->eventDispatcher » :

use Symfony\Component\EventDispatcher\EventDispatcherInterface;
class BlogController extends AbstractController
{
    private EventDispatcherInterface $eventDispatcher;
    public function __construct(EventDispatcherInterface $eventDispatcher)
    {
        $this->eventDispatcher = $eventDispatcher;
    }
...
    $dispacher = $this->eventDispatcher;
    $dispatcher->addListener('kernel.response', array($betaListener, 'onKernelResponse'));

2) Il faut remplacer : -> « FilterResponseEvent » par « ResponseEvent » -> « GetResponseEvent » par « RequestEvent » -> « GetResponseForControllerResultEvent » par « ViewEvent »

Nouveau dans Symfony 4.3

Mise à jour des classes d'événements de HttpKernel

En plus du changement précédent, nous avons également mis à jour les classes des événements que Symfony passe pour ses propres événements. 
Les nouveaux noms sont beaucoup plus intuitifs et concis :

FilterControllerArgumentsEvent devient ControllerArgumentsEvent
FilterControllerEvent devient ControllerEvent
FilterResponseEvent devient ResponseEvent
GetResponseForControllerResultEvent devient ViewEvent.
GetResponseForExceptionEvent devient ExceptionEvent.
PostResponseEvent devient TerminateEvent

3) Il faut remplacer les « ::MASTER_REQUEST » par « MAIN_REQUEST » (déprécié depuis symfony/http-kernel 5.3, utilisez MAIN_REQUEST à la place)

4) Il faut remplacer « use Symfony\Component\EventDispatcher\Event; » par : « use Symfony\Contracts\EventDispatcher\Event; »

5) Voici ma version de la méthode ajouterAction() :

class BlogController extends AbstractController
{
 private EventDispatcherInterface $eventDispatcher;

 public function __construct(EventDispatcherInterface $eventDispatcher)
 {
     $this->eventDispatcher = $eventDispatcher;
 }


...

 public function ajouter(Request $request)
 {
     $article = new Article;
     $form = $this->createForm(ArticleType::class, $article);
     $form->handleRequest($request);
 
     if ($form->isSubmitted() && $form->isValid()) {
     
         // On crée l'évènement avec ses 2 arguments
         $event = new MessagePostEvent($article->getContenu(), $this->getUser());

         // On déclenche l'évènement
         $dispacher = $this->eventDispatcher;
         $dispacher->dispatch($event ,BigbrotherEvents::onMessagePost);

         $article->setContenu($event->getMessage());

         $em = $this->getDoctrine()->getManager();
         $em->persist($article);
         $em->flush();

         $this->get('session')->getFlashBag()->add('info', 'Article bien ajouté');
 
         return $this->redirectToRoute('blog_accueil');
     }
 
     return $this->render('blog/ajouter.html.twig', array(
         'form' => $form->createView(),
     ));
 }

6) Voici ma version de la class CensureListener :

<?php

namespace App\Bigbrother;

use Symfony\Component\Mailer\MailerInterface;
use Symfony\Component\Mime\Email;
use Symfony\Component\Security\Core\User\UserInterface;

class CensureListener
{
    // Liste des id des utilisateurs à surveiller
    protected $liste;
    protected $mailer;

    public function __construct(array $liste, MailerInterface $mailer)
    {
        $this->liste = $liste;
        $this->mailer = $mailer;
    }

    // Méthode « reine » 1
    protected function sendEmail($message, UserInterface $user)
    {
        $message = (new Email())
            ->subject("Nouveau message d'un utilisateur surveillé")
            ->from('admin@votresite.com')
            ->to('monmail@bidule.com')
            ->text("L'utilisateur surveillé '" . $user->getUserIdentifier() . "' a posté le message suivant : '" . $message . "'");

        $this->mailer->send($message);
    }

    // Méthode « reine » 2
    protected function censureMessage($message)
    {
        // Ici, totalement arbitraire :
        $message = str_replace(array('top secret', 'mot interdit'), '', $message);

        return $message;
    }

    // Méthode « technique » de liaison entre l'évènement et la fonctionnalité reine
    public function onMessagePost(MessagePostEvent $event)
    {
        // On active la surveillance si l'auteur du message est dans la liste
        if (in_array($event->getUser()->getId(), $this->liste)) {
            // On envoie un e-mail à l'administrateur
            $this->sendEmail($event->getMessage(), $event->getUser());

            // On censure le message
            $message = $this->censureMessage($event->getMessage());
            // On enregistre le message censuré dans l'event
            $event->setMessage($message);
        }
    }
}

Dans cette classe, il faut remplacer :

->setBody("L’utilisateur surveillé '".$user->getUsername()."' a posté le message suivant :

par :

->setBody("L’utilisateur surveillé '".$user-> getUserIdentifier ()."' a posté le message suivant :

Source :

Une autre source de confusion liée aux utilisateurs est le concept de "nom d'utilisateur" qui est utilisé dans la sécurité de Symfony. Dans de nombreuses applications, ce nom d'utilisateur n'est pas un nom d'utilisateur traditionnel, mais un email ou même un jeton d'API.

C'est pourquoi dans Symfony 5.3 nous avons décidé d'éviter cette confusion et nous avons renommé "username" en "user identifier". Cela peut nécessiter quelques changements dans le code de votre application (dans 5.3 les anciens noms fonctionnent toujours mais ils sont dépréciés et dans Symfony 6.0 ils seront supprimés).

7) Après la phrase « Et bien sûr, la définition du service qui convient » j’ai :


    blog.censure_listener:    
        class: App\Bigbrother\CensureListener
        arguments:
            $liste: [1, 2]
        tags:
            - { name: kernel.event_listener, event: blog.bigbrother.post_message, method: onMessagePost }

Voilà, j’espère que ça aidera.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte