Que faire d'une classe supprimée dans Sylius 2 ?
Quand une classe que votre code utilise a disparu dans Sylius 2, ouvrez le fichier UPGRADE-2.0 officiel : il indique si elle a été renommée ou déplacée, remplacée par un composant Symfony, ou supprimée avec la fonctionnalité qu'elle servait. Dans les deux premiers cas, la correction est mécanique. Dans le troisième, il faut reconstruire le besoin avec les nouveaux outils de Sylius 2, ce qui relève du développement et non du simple renommage.
Je suis développeur Sylius indépendant et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. Les classes et services supprimés sont l'une des premières causes d'écran d'erreur au démarrage d'une branche Sylius 2. Voici comment je les traite, et ce que cela signifie pour le calendrier de votre chantier.
Que dit la documentation officielle sur les classes supprimées ?
Le guide officiel UPGRADE-2.0 consacre une section entière aux changements de services, de classes et d'interfaces. On y trouve plusieurs listes distinctes, qu'il faut lire séparément car elles n'appellent pas la même correction : les classes et interfaces supprimées, les services et alias supprimés, la table des anciens identifiants de services et de leurs nouveaux noms, les classes déplacées d'un bundle à l'autre, les constructeurs dont la signature a changé et les champs retirés des modèles d'utilisateur. Le résumé utilisé sur le site, plus de 150 classes supprimées, donne l'ordre de grandeur.
Le guide 2.0 n'est pas le seul à lire. Chaque version 2.x publie son propre fichier UPGRADE, avec des changements de signature et des dépréciations annoncées pour Sylius 3.0. Si vous visez la 2.3, lisez toute la chaîne jusqu'à elle, et traitez les dépréciations au passage pour ne pas préparer la prochaine rupture.
Quels sont les quatre cas possibles ?
La classe ou le service a seulement changé de nom ou de place
C'est le cas le plus simple. Les alias introduits en 1.14 sont devenus les identifiants principaux en 2.0, et les anciens identifiants ont été supprimés. Le service du formulaire d'ajout au panier, par exemple, passe de sylius.form.type.add_to_cart à sylius.form.type.order.add_to_cart. Certaines classes changent de bundle : le contexte de thème ChannelBasedThemeContext passe du CoreBundle au ShopBundle. Côté API, le dossier Message devient Command et MessageHandler devient CommandHandler. Il suffit de mettre à jour les références, ce qui peut même se faire sur la 1.14 pour les alias déjà disponibles.
La classe est remplacée par un composant Symfony
Sylius 2 s'appuie davantage sur Symfony. Le paquet sylius/calendar est remplacé par symfony/clock : toute utilisation de DateTimeProviderInterface devient une utilisation de ClockInterface. SwiftMailer laisse la place à symfony/mailer. La machine à états winzou cède la place par défaut à Symfony Workflow. La correction demande un peu plus qu'un renommage, car les méthodes ne sont pas identiques, mais le chemin est balisé. Pour les transitions de commande, je renvoie à l'article sur la migration de winzou vers Symfony Workflow.
La classe a disparu avec sa fonctionnalité
Ici, il n'y a pas d'équivalent direct. Les pilotes Doctrine ODM pour MongoDB et PHPCR sont retirés. Le contrôleur ProductSlugController et les routes AJAX de l'administration disparaissent, car Sylius 2 génère ces comportements autrement, avec Symfony UX et les composants Twig. La logique du code PIN de réinitialisation de mot de passe est supprimée. Si votre code s'appuyait sur l'une de ces classes, il faut revenir au besoin métier et le reconstruire avec les outils de Sylius 2.
Le service existe toujours, mais n'est plus accessible comme avant
C'est le cas le plus sournois, car la classe n'a pas disparu. En Sylius 2.0, les services sont privés par défaut. La documentation du conteneur de services Symfony le rappelle : un service privé ne peut pas être récupéré par un appel direct au conteneur, seule l'injection de dépendances fonctionne. Un code qui faisait un appel du type get sur le conteneur pour obtenir un service Sylius casse, alors que le service est bien là. La correction consiste à l'injecter par le constructeur.
| Cas | Exemple tiré du guide | Type de correction |
|---|---|---|
| Renommé ou déplacé | sylius.form.type.add_to_cart devient sylius.form.type.order.add_to_cart | Mécanique |
| Remplacé par Symfony | DateTimeProviderInterface remplacé par ClockInterface | Mécanique avec relecture |
| Supprimé avec la fonctionnalité | ProductSlugController, pilotes ODM | Développement |
| Devenu privé | Service Sylius lu directement dans le conteneur | Refactorisation par injection |
Comment repérer toutes les classes supprimées dans votre code ?
La pire méthode est d'attendre les erreurs une par une. Symfony compile le conteneur au démarrage, et chaque identifiant manquant bloque l'application : vous corrigez une erreur, la suivante apparaît, et vous ne savez jamais combien il en reste. Impossible de donner une date dans ces conditions.
J'ai créé Sylius Upgrade Analyzer en partie pour ce problème. Cet outil open source, publié sur le Sylius Store, compare votre code aux listes du guide officiel : classes supprimées, identifiants de services renommés, classes déplacées, constructeurs modifiés, appels directs au conteneur, routes retirées. Il donne la liste complète en une passe, avec une estimation par problème. Ses corrections automatiques mettent à jour les classes déplacées et les identifiants renommés, et marquent d'un commentaire TODO les références aux classes supprimées, pour qu'aucune ne passe inaperçue. Je relis chaque correction avant de la garder.
Une fois le gros du travail fait, la commande lint:container de Symfony effectue des vérifications supplémentaires sur la configuration des services. Je l'ajoute à l'intégration continue de la branche Sylius 2, avec une analyse statique du code, pour attraper ce qui reste.
Si vous voulez savoir combien de classes et de services sont touchés dans votre projet avant de vous engager, c'est exactement ce que mesure le diagnostic de migration Sylius 2 que je propose.
Faut-il recopier la classe supprimée dans son propre code ?
C'est tentant, et parfois défendable comme pont temporaire : une petite classe autonome, sous licence permissive, recopiée dans votre espace de noms pour débloquer la migration. Mais vous en devenez le mainteneur, et elle ne suivra plus les corrections de sécurité de Sylius. Si la classe dépend d'un bundle lui aussi retiré, comme SyliusUiBundle ou Sonata Block, la copie ne fait que déplacer l'erreur. Dans la majorité des cas, la bonne réponse reste d'adopter le remplaçant officiel.
Pour l'interface boutique, un cas particulier existe : le LegacyShopBridgePlugin restaure une partie de l'ancien système de gabarits et des contrôleurs retirés, pour migrer le front en plusieurs étapes. Je le présente dans l'article sur la migration progressive avec le LegacyShopBridgePlugin.
Ce que je vous propose
Une classe supprimée n'est grave que si on la découvre tard. Repérée au diagnostic, elle devient une ligne chiffrée du chantier. Le support de sécurité de Sylius 1.14 s'arrête le 31 décembre 2026 : mieux vaut connaître la liste complète maintenant que la découvrir erreur après erreur.
Je lance Sylius Upgrade Analyzer sur votre projet, je classe chaque classe et chaque service touché selon ces quatre cas et je vous remets un diagnostic offert avec une estimation en jours.