Sylius 2 : vais-je retrouver mes fiches produits ?

Oui, vous retrouverez vos fiches produits, leurs déclinaisons, leurs attributs et leurs catégories après la migration vers Sylius 2, sans ressaisie. La migration se fait sur votre base existante, mise à niveau par une migration Doctrine, et le modèle de catalogue de Sylius est le même en version 1 et en version 2. Ce qui demande de l'attention, ce sont les données ajoutées par votre propre code, les images et les types d'attributs maison.

Je suis Pierre-Arthur Demengel, développeur Sylius indépendant. Quand un dirigeant me pose cette question, il pense à ses années de travail sur le catalogue : les descriptions réécrites, les déclinaisons patiemment créées, l'arborescence affinée. Cette inquiétude est légitime, et la réponse rassurante n'a de valeur que si elle s'accompagne d'une méthode de contrôle.

Les fiches produits sont-elles migrées automatiquement ?

Elles ne sont pas « migrées » au sens d'un transfert d'un logiciel à un autre : elles restent dans la même base, dans les mêmes tables. Le guide officiel UPGRADE-2.0 précise que les migrations Doctrine de Sylius ont été régénérées en un seul fichier, appliqué avec la commande habituelle doctrine:migrations:migrate. Cette migration ajuste le schéma là où Sylius 2 l'exige, sans repartir de zéro. La question de la base dans son ensemble est traitée dans l'article sur la conservation de la base de données, et le cas des anciens fichiers de migration dans celui sur les anciennes migrations Doctrine.

Que deviennent les déclinaisons, attributs et catégories ?

Les déclinaisons et options

Vos variantes gardent leur code, leurs options (taille, couleur, matière), leur stock et leurs prix par canal. Côté API, les valeurs d'options sont désormais exposées sous leur option, et leur identifiant numérique n'apparaît plus dans les réponses, comme le montre le guide UPGRADE-API-2.0. Cela ne change rien à vos données, mais un outil externe qui s'appuyait sur cet identifiant doit utiliser le code.

Les attributs

Les attributs standard (texte, nombre, date, choix, case à cocher) et leurs valeurs traduites sont repris. Sylius 2 ajoute un champ position sur les attributs, utile pour les ordonner. En revanche, un type d'attribut créé par votre développeur, par exemple une liste liée à un référentiel externe, repose sur du code : sa valeur reste en base, mais son formulaire d'administration et son affichage en boutique doivent être adaptés.

Les catégories

Vos taxons sont repris avec leur hiérarchie, leurs positions, leurs slugs et leurs traductions. L'écran de l'arbre des catégories change d'apparence dans l'administration, puisque les routes qui le chargeaient en Ajax ont été retirées au profit de composants Symfony UX, mais l'arborescence elle-même ne bouge pas.

Quels points de vigilance sur les données produits ?

Sur les boutiques que j'ai migrées, trois sujets reviennent. Le premier concerne les champs ajoutés aux entités produit ou variante par votre projet : poids logistique, code fournisseur, mention réglementaire. Leurs colonnes restent en base, mais leur déclaration, leurs formulaires et leurs gabarits sont à vérifier un par un. Le deuxième concerne les images. Sylius 2 renomme le resolver et le loader par défaut de LiipImagineBundle, de default à sylius_image, et standardise les tailles d'images : votre configuration doit être relue et les vignettes régénérées. Le troisième concerne les adresses des fiches : les slugs sont conservés, mais une route personnalisée ou un gabarit réécrit peut modifier une URL sans qu'on le remarque. Ce contrôle est détaillé dans l'article sur les URL après la migration.

Pour repérer ces points dans le code, je lance Sylius Upgrade Analyzer, l'outil que j'ai créé et publié sur le Sylius Store. Il relève les gabarits surchargés, les formulaires et les configurations concernés, avec une estimation en heures. Si vous voulez ce relevé pour votre catalogue, il fait partie du diagnostic de migration offert.

Comment vérifier qu'aucune fiche n'a été perdue ?

Une affirmation ne suffit pas, il faut des preuves. Ma méthode tient en trois contrôles, menés sur une copie de la production avant la bascule, puis refaits le jour J.

D'abord des comptages. Avant la migration, je relève le nombre de produits, de variantes, d'options et de valeurs, d'attributs et de valeurs d'attributs, de taxons, d'images et de traductions, canal par canal. Après la migration, les mêmes requêtes doivent donner les mêmes chiffres. Le moindre écart est expliqué avant d'aller plus loin.

Ensuite un échantillon. Je choisis avec votre responsable catalogue une vingtaine de fiches représentatives, dont les plus compliquées : beaucoup de déclinaisons, des attributs particuliers, plusieurs catégories, plusieurs langues. On les compare côte à côte en Sylius 1 et en Sylius 2, en boutique et en administration.

Enfin les parcours. On cherche un produit, on filtre une catégorie, on choisit une déclinaison, on l'ajoute au panier. Une donnée présente mais mal affichée est aussi gênante pour un client qu'une donnée perdue.

Ce que je vous propose

Je lance l'analyseur sur votre projet, je relève les données produits portées par du code maison, la configuration des images et les flux qui alimentent le catalogue, et je vous remets un rapport commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Le support de sécurité de Sylius 1.14 s'arrête le 31 décembre 2026 : savoir dès maintenant ce que demande votre catalogue évite de découvrir un attribut cassé la veille de la bascule.