L’article explique comment moderniser un système de logging dans Symfony en remplaçant les déclencheurs (triggers) traditionnels par les événements Doctrine, une approche plus flexible et maintenable. L’auteure, Jinal Solanki, détaille les limites des triggers (dépendance à la base de données, manque de souplesse) et propose une solution basée sur les listeners Doctrine pour intercepter les opérations CRUD (Create, Read, Update, Delete) directement dans le code PHP. Cette méthode permet de centraliser la logique de logging, de faciliter les tests unitaires et d’éviter les effets de bord liés aux triggers SQL. Elle illustre la mise en œuvre avec des exemples concrets : création d’un EventSubscriber pour écouter les événements prePersist, preUpdate et preRemove, puis enregistrement des changements dans une table dédiée. L’avantage principal est une meilleure intégration avec le code métier, une maintenance simplifiée et une indépendance vis-à-vis du SGBD. Une solution idéale pour rendre le logging évolutif et cohérent dans une architecture Symfony.

L’article présente l’utilisation de Make pour simplifier et standardiser les commandes courantes dans un projet Symfony, surtout en environnement Docker. L’auteur partage ses Makefiles personnalisés, qui permettent de lancer des tâches comme l’installation des dépendances (make composer), l’exécution des tests (make test), l’analyse statique (make static-analysis), ou encore la gestion de la base de données (make db-reset), le tout avec des paramètres optionnels pour l’environnement (env=prod) ou des arguments supplémentaires (arg=--testdox). Grâce à Make, les commandes Docker complexes deviennent simples et documentées (ex: make qa pour lancer la vérification de code, l’analyse statique et les tests en une seule commande). L’article propose trois versions de Makefile : pour Docker Compose, Docker seul, et PHP natif, inspirées du projet symfony-docker. L’objectif est d’améliorer la productivité en évitant de retaper des commandes longues et en centralisant la documentation des tâches disponibles. Une solution élégante pour uniformiser les workflows entre projets Symfony.

PHP 8.4 et Doctrine 3.4 révolutionnent la gestion des propriétés avec les Property Hooks : fini les centaines de lignes de getters/setters ! Désormais, il est possible d’intégrer directement la logique d’accès et de modification dans la déclaration des propriétés, réduisant drastiquement le code boilerplate (jusqu’à -60%). Par exemple, au lieu d’écrire des méthodes getName() et setName(), on utilise une syntaxe élégante comme public string $name { get => strtoupper($this->name); set => $this->name = trim($value); }. Doctrine 3.4 supporte officiellement cette fonctionnalité, simplifiant ainsi les entités et améliorant la lisibilité. La migration, bien que bénéfique (moins de code, meilleure maintenance), demande une adaptation du code existant et des tests rigoureux. Une avancée majeure pour le PHP moderne, même si certains outils ou habitudes mettent du temps à s’adapter.

Biome est présenté comme un outil révolutionnaire pour les développeurs front-end, remplaçant efficacement ESLint et Prettier. Il combine les fonctionnalités d'un formatter, d'un linter, et d'un analyseur statique en un seul binaire, offrant une solution plus rapide et moins complexe. Biome simplifie la configuration, réduit le besoin de multiples outils, et améliore la cohérence du code. Il est particulièrement apprécié pour sa rapidité et sa facilité d'intégration, notamment dans des projets Symfony via le bundle kocal/biome-js-bundle. Bien qu'il ne couvre pas 100% des cas d'utilisation d'ESLint, il est efficace dans 90% des situations courantes. Biome impose également des conventions strictes pour des pratiques de codage cohérentes, comme l'utilisation de points-virgules et de virgules finales. En résumé, Biome est une solution tout-en-un qui simplifie le développement et améliore la productivité.

L'articleremet en question l'utilisation des service subscribers, une pratique courante dans les projets Symfony pour gérer les dépendances occasionnelles. L'auteur propose une alternative en utilisant des événements et des écouteurs pour cibler les dépendances nécessaires, plutôt que de tout centraliser dans une seule classe. Par exemple, au lieu d'utiliser un AbstractController et de charger toutes les dépendances dans le constructeur, il suggère de créer des événements spécifiques pour chaque action (comme l'envoi d'un e-mail ou la génération d'un PDF) et d'utiliser des écouteurs pour gérer ces événements. Cela permet une meilleure séparation des responsabilités et une plus grande flexibilité. L'article conclut en encourageant les développeurs à réfléchir avant d'utiliser des service subscribers et à envisager d'autres moyens pour éviter les dépendances occasionnelles, comme l'injection de dépendances directement dans les méthodes des contrôleurs.

L'article aborde un problème courant mais critique dans les projets Symfony utilisant Doctrine et le Symfony Serializer. L'auteur décrit une expérience de débogage où une erreur de mémoire épuisée a été causée par l'utilisation négligente du serializer par défaut de Symfony, qui utilise les métadonnées de Doctrine, entraînant une consommation excessive de mémoire. Le problème est survenu lors de la sérialisation de grandes quantités de données dans une entité contenant de grands champs JSON. La solution proposée consiste à créer un adaptateur de serializer léger qui évite complètement les métadonnées de Doctrine. L'article souligne l'importance d'utiliser des serializers adaptés pour les données internes de débogage ou de sauvegarde et met en garde contre l'utilisation du serializer par défaut pour les entités avec de grandes ou des données imbriquées, afin de rester en contrôle de l'utilisation de la mémoire.

L'article explique comment prioriser les messages dans les applications asynchrones utilisant Symfony Messenger. Il aborde les défis liés à la gestion des messages de différentes priorités et propose des solutions pour s'assurer que les messages critiques sont traités en temps opportun. L'auteur suggère de diviser les messages en plusieurs files d'attente basées sur leur priorité et d'utiliser des stamps personnalisés pour router dynamiquement les messages. De plus, il recommande de diviser les tâches longues en messages plus petits pour éviter de bloquer les travailleurs et garantir un flux fluide dans la file d'attente.

L'article explore les méthodes de test des messages différés dans Symfony Messenger en utilisant Behat. L'auteur décrit un projet où des opérations sont planifiées pour être traitées de manière asynchrone à l'avenir, parfois après quelques minutes, parfois après plusieurs heures. L'objectif est de se concentrer sur le résultat plutôt que sur la planification elle-même. L'article propose une solution pour "voyager" à travers le temps, traiter les travaux planifiés et vérifier les résultats attendus. Il utilise des scénarios Gherkin pour illustrer l'escalade de priorité des incidents en fonction du temps et explique comment configurer les entités, les messages et les transports dans Symfony pour gérer ces scénarios. Enfin, il montre comment créer un transport Messenger personnalisé pour contrôler quels travaux en arrière-plan sont traités et quand, en utilisant le composant Cache de Symfony pour persister temporairement les messages planifiés.

Suite et correction de https://dev.to/altesack/strategy-pattern-in-symfony-4o9h , dans le cadre d'une utilisation du Design Pattern Stratefy, l'auteur explique qu'il préfère désormais utiliser les attributs plutôt que services.yml . Il utilise aussi une méthode "supports" pour vérifier si une stratégie est applicable

L'article décrit comment une équipe a optimisé le temps de récupération des données d'API dans un projet Symfony, réduisant le temps de traitement de 40 minutes à seulement 10 minutes. En utilisant des requêtes concurrentes et des techniques de parallélisation, ils ont pu gérer plusieurs appels API simultanément, améliorant ainsi considérablement l'efficacité et les performances de leur application. Cette approche a permis de réduire le temps d'exécution global et d'optimiser la gestion des ressources.

Symfony dispose de fonctionnalités sur les chaînes de caractères depuis longtemps (Symfony 5) avec plein d'utilitaires très pratiques : gestion de l'unicode, enchaînement de méthodes (interface fluente), prise en charge de l'internationalisation, etc.

L'article explique comment implémenter le design pattern Strategy dans Symfony 7 pour gérer des comportements différents sous certaines conditions sans utiliser de multiples instructions if. Ce modèle permet de créer des stratégies distinctes et testables individuellement, rendant le code plus élégant et professionnel. L'article décrit la structure du modèle, composée d'une classe de contexte, de classes de stratégie individuelles et de classes auxiliaires. Trois exemples concrets sont fournis : une règle métier, des opérations avec API Platform, et une recherche intelligente avec Doctrine. L'utilisation du pattern Strategy dans Symfony 7 est présentée comme une solution efficace pour centraliser et simplifier la gestion des comportements variés dans une application.

L'article explique comment améliorer la structure et la performance des services dans Symfony en utilisant les "service subscribers". Il commence par souligner les problèmes liés au chargement automatique de nombreux services, qui peuvent entraîner une instanciation inutile de dépendances et compliquer l'extensibilité. La solution proposée est d'implémenter l'interface ServiceSubscriberInterface, ce qui permet de charger les services de manière paresseuse, c'est-à-dire uniquement lorsqu'ils sont réellement nécessaires. L'article montre également comment créer une classe de base abstraite pour centraliser la logique des services, améliorant ainsi la maintenabilité et l'expérience des développeurs. Enfin, il aborde l'utilisation de cette approche dans un bundle Symfony pour gérer des dépendances optionnelles, rendant les services plus modulaires et légers.

Symfony 7.3 introduit le composant Object Mapper qui simplifie la transformation d'entités en DTOs. L'auteur montre plusieurs cas d'utilisations, du mapping direct (propriété identique) au mapping avec transformation, en passant par les mapping de types complexes.
Il conclue en discutant des avantages de ce composant.

L'auteur montre comment implémenter la double authentification dans Symfony, en utilisant quelques dépendances externes :

• OTPHP - une librairie qui permet de gérer les TOTP, mots de passe à usage unique basés sur le temps
• Endroid/QrCode - pour générer les QR codes
• Scheb/2fa-bundle - le bundle de double authentification de Symfony

L'article explore l'utilisation conjointe des modèles de conception "Stratégie" et "Chaîne de Responsabilité" dans le cadre du développement avec Symfony. L'auteur commence par démystifier ces concepts, souvent perçus comme complexes, en illustrant comment ils sont déjà utilisés inconsciemment dans le développement quotidien. Il explique le modèle "Stratégie" à travers un exemple de planification de voyage, où différentes stratégies de transport peuvent être interchangeables selon le contexte. Ensuite, il aborde le modèle "Chaîne de Responsabilité" en décrivant comment les requêtes peuvent être traitées séquentiellement par une série de gestionnaires, chacun ayant la possibilité de traiter ou de transmettre la requête. L'auteur montre comment Symfony facilite l'intégration de ces modèles grâce à des attributs modernes comme AutoconfigureTag et AutowireIterator, permettant une implémentation élégante et maintenable. Enfin, il souligne les avantages de cette combinaison pour créer des applications flexibles, découplées et faciles à étendre.

L'article explique comment intégrer un système d'authentification unique (SSO) dans une application Symfony. Il décrit les avantages d'un authentificateur SSO personnalisé, tels que l'uniformité de l'authentification et une sécurité renforcée grâce à des fonctionnalités comme l'authentification multifacteur. L'article détaille le flux de travail de haut niveau, incluant la redirection vers un fournisseur d'identité, l'échange de codes d'autorisation, et la création d'un jeton de session. Il fournit également des instructions sur la configuration des dépendances, la mise en place d'un authentificateur personnalisé, et la configuration de l'environnement. Enfin, l'article conclut en soulignant les bénéfices de cette approche, notamment la modularité et l'amélioration de l'expérience utilisateur.

L'article explore comment appliquer les principes SOLID dans le cadre du développement avec Symfony. Voici un aperçu des points clés abordés :

1. Single Responsibility Principle (SRP) : L'article explique comment structurer les classes dans Symfony pour qu'elles aient une seule responsabilité, facilitant ainsi la maintenance et les tests.

2. Open/Closed Principle (OCP) : Il montre comment concevoir des composants Symfony qui sont ouverts à l'extension mais fermés à la modification, en utilisant des techniques comme l'héritage et les interfaces.

3. Liskov Substitution Principle (LSP) : L'article discute de l'importance de s'assurer que les objets des sous-classes peuvent remplacer ceux des classes de base sans affecter le comportement du programme, un concept crucial pour la réutilisabilité du code.

4. Interface Segregation Principle (ISP) : Il met en avant l'avantage d'utiliser plusieurs interfaces spécifiques plutôt qu'une seule interface générale, permettant aux classes de n'implémenter que les méthodes nécessaires.

5. Dependency Inversion Principle (DIP) : L'article souligne l'importance de dépendre des abstractions plutôt que des implémentations concrètes, en utilisant l'injection de dépendances et les interfaces pour rendre le code plus flexible et réutilisable.

En appliquant ces principes, les développeurs peuvent créer des applications Symfony plus robustes, maintenables et évolutives. L'article fournit des exemples pratiques et des conseils pour intégrer ces principes dans les projets Symfony.

L'article explique comment installer DaisyUI dans un projet Symfony en utilisant le composant AssetMapper. Il montre aussi comment choisir la version de Tailwind (version 4)

L'article explique l'intérêt de mettre en place l'observabilité, et il montre comment le faire pour une application Symfony en utilisant Sentry.