Plugins Sylius compatibles Sylius 2 : vérifier, remplacer

Un plugin Sylius est compatible avec Sylius 2 quand une version stable publiée sur Packagist déclare une contrainte sur sylius/sylius qui accepte la 2.x, par exemple ^2.0, et qu'elle fonctionne réellement sur votre boutique. On le vérifie en cinq contrôles : le composer.json du plugin, Packagist, le Sylius Store, les branches GitHub, puis un test sur branche. Pour un plugin non porté, il reste quatre issues : le remplacer, le forker, réécrire la fonction dans votre code ou l'abandonner.

Pourquoi les plugins sont-ils le premier risque d'une migration Sylius 2 ?

Le cœur de Sylius a un chemin officiel : monter en 1.14, supprimer les dépréciations, puis appliquer le fichier UPGRADE-2.0.md et les suivants jusqu'à la version cible. Les plugins n'ont pas ce filet. Ils touchent précisément les zones qui ont le plus changé : les gabarits branchés sur les template events (supprimés au profit des Twig Hooks), la machine à états winzou (remplacée par défaut par Symfony Workflow), les ressources API Platform 2.7 (passées en version 4), l'administration en Semantic UI et jQuery (remplacée par Bootstrap 5 et Symfony UX).

Un plugin resté en 1.x ne pose pas un petit problème d'affichage : Composer refuse de résoudre les dépendances et toute la montée de version reste bloquée. Sur les montées de version Sylius 1.x vers 2.x que j'ai menées pour des boutiques en production, la liste des plugins est la première chose que je regarde, avant même le code sur mesure. C'est elle qui transforme un chantier prévisible en développement imprévu. Le calendrier ajoute la pression : selon le cycle de versions officiel, la 1.14 n'a plus de support de sécurité après le 31 décembre 2026.

Comment vérifier qu'un plugin Sylius est compatible avec Sylius 2 ?

Faites les cinq contrôles dans cet ordre. Les deux premiers suffisent souvent ; les suivants servent à trancher les cas douteux.

1. Lire le composer.json du plugin, pas celui du projet

Ouvrez le fichier composer.json du plugin dans le dossier vendor et cherchez la contrainte sur sylius/sylius ou sur les paquets du cœur, comme sylius/core-bundle. Une contrainte ^1.12 ou ~1.13.0 exclut la 2.x. Une contrainte ^1.13 || ^2.0 ou ^2.0 l'accepte. Regardez aussi les dépendances retirées de Sylius 2 : friendsofsymfony/rest-bundle, jms/serializer-bundle, sonata-project/block-bundle, swiftmailer. Leur présence trahit un plugin resté sur l'architecture 1.x.

2. Interroger Packagist et Composer

Sur Packagist, la page du paquet liste chaque version publiée et ses exigences. Ce qui compte : une version stable, pas seulement une branche de développement, dont la contrainte accepte votre version cible. Sur le projet, la commande composer why-not sylius/sylius 2.3.0 liste d'un coup les paquets qui empêchent l'installation. C'est la méthode la plus rapide pour obtenir la liste complète des blocages.

Trois exemples vérifiés sur Packagist le 4 novembre 2026. Le plugin officiel sylius/invoicing-plugin en v2.3.0, publié le 8 octobre 2026, demande sylius/sylius ^2.0. Le plugin officiel sylius/refund-plugin en v2.2.1, publié le 6 octobre 2026, demande aussi ^2.0. En revanche, la dernière version publiée de bitbag/cms-plugin, la v4.4 du 5 mars 2025, demande sylius/sylius ^1.13 : à cette date, aucune version stable de ce paquet n'est publiée pour Sylius 2. Ces statuts évoluent : refaites le contrôle le jour où vous planifiez.

3. Consulter la fiche du Sylius Store

Le Sylius Store affiche sur chaque fiche un champ « Sylius version ». C'est une bonne première lecture, mais c'est une déclaration de l'éditeur, qui peut retarder sur Packagist. En cas de désaccord, Packagist fait foi.

4. Regarder les branches et l'activité GitHub

Une branche 2.x ou une pull request intitulée « Sylius 2 support » signale un portage en cours. Regardez la date du dernier commit, les issues restées sans réponse et le nombre de mainteneurs actifs. Une branche de portage jamais publiée en version stable n'est pas une compatibilité : installer dev-main en production, c'est accepter des changements sans préavis.

5. Tester l'installation sur une branche

Le seul verdict définitif : une branche du projet en Sylius 2, l'installation du plugin, puis un parcours de commande complet et les écrans d'administration concernés. Un plugin peut s'installer et casser à l'exécution : un bloc qui ne s'affiche plus parce que son hook n'existe pas, une transition de commande ignorée, un endpoint d'API absent.

Peut-on automatiser cette vérification sur tout le projet ?

Oui pour l'inventaire. J'ai créé Sylius Upgrade Analyzer, un outil en ligne de commande open source sous licence MIT, qui s'exécute en local. Parmi ses 49 analyseurs, l'un vérifie les plugins installés contre le Sylius Store et Packagist ; d'autres repèrent dans votre code les template events, les callbacks winzou et les ressources API Platform à reprendre. Il s'installe avec composer require --dev pierre-arthur/sylius-upgrade-analyzer et se lance avec vendor/bin/sylius-upgrade-analyzer sylius-upgrade:analyze --target-version=2.3. Le rapport sort en console, JSON, CSV, SARIF ou Markdown.

La limite est nette : l'outil vous dit quels plugins bloquent, il ne les porte pas à votre place et il ne prouve pas leur comportement à l'exécution. Le test sur branche reste obligatoire. Le détail de ce qu'il couvre est dans mon article sur l'audit avec Sylius Upgrade Analyzer.

Que faire si un plugin n'est pas porté vers Sylius 2 ?

Quatre issues, à choisir plugin par plugin, selon la place de la fonction dans vos ventes et la taille du code concerné.

Remplacer. Cherchez un plugin maintenu qui couvre le même besoin, chez l'éditeur officiel ou ailleurs. C'est souvent l'option la moins chère, mais elle impose une reprise de données : les tables de l'ancien plugin ne correspondent pas à celles du nouveau.

Forker. Vous reprenez le code, vous le portez sur Sylius 2 et vous le maintenez. Cela convient quand le plugin est petit, que sa licence le permet et que le besoin est durable. Le coût caché est la maintenance à chaque version mineure 2.x.

Réécrire. Si vous n'utilisez qu'une partie du plugin, réécrivez cette partie dans votre propre code, avec les Twig Hooks et Symfony Workflow. C'est fréquent : un plugin généraliste et volumineux sert parfois une seule règle métier.

Abandonner. Une fonction installée il y a des années et que personne n'utilise plus n'a pas à suivre la migration. Vérifiez les statistiques d'usage, exportez les données utiles, puis retirez le plugin.

Que vaut le guide officiel de migration des plugins ?

Sylius publie un guide de migration des plugins vers 2.0, encore marqué expérimental. Il sert de base si vous forkez ou réécrivez un plugin, mais ne le prenez pas pour une procédure garantie. Le paquet sylius/sylius-rector propose des règles automatiques pour des plugins et pour Sylius Plus, pas pour le cœur d'une boutique 1.14. Rector corrige le PHP mécanique : espaces de noms, signatures, appels dépréciés. Le passage des gabarits Semantic UI vers Bootstrap 5 et les Twig Hooks, lui, reste manuel. Pour ces deux chantiers, voyez le guide pratique des Twig Hooks et la migration de winzou vers Symfony Workflow.

Si un plugin de la boutique publique bloque tout, une migration progressive est parfois possible : le cœur passe en 2.x pendant que la boutique garde son interface 1.x. C'est l'objet de l'article sur le LegacyShopBridgePlugin, avec ses limites pour les plugins tiers.

Par où commencer cette semaine ?

Lancez la commande composer why-not sur votre projet, ou Sylius Upgrade Analyzer si vous voulez le statut de chaque plugin et l'inventaire du code à reprendre dans le même rapport. Classez ensuite chaque plugin bloquant dans une des quatre issues. Si vous préférez un regard extérieur, je lance l'analyse sur votre projet et je vous remets un diagnostic de migration Sylius 2 offert, avec le statut de chaque plugin et une estimation en jours du chantier.