Migrer une boutique PrestaShop 8 vers la 9 : ce qui casse vraiment

Symfony passe de 4.4 à 6.4 et FrameworkBundleAdminController disparaît. Inventaire de ce qui casse, module par module, et de ce qui ne bouge pas.

Ce qui casse vraiment

Entre PrestaShop 8 et 9, ce n'est pas PrestaShop qui bouge, c'est Symfony dessous : on passe de la 4.4 à la 6.4. Deux versions majeures d'écart, et tout ce qui touchait aux contrôleurs d'administration en prend note.

La classe qui disparaît

Le point de rupture principal tient en un nom : FrameworkBundleAdminController. C'était la classe de base de tout contrôleur d'admin dans un module. Elle est dépréciée en 9, promise à la suppression en 10, et surtout elle portait un raccourci qui n'existe plus : $this->get(), qui permettait d'attraper n'importe quel service au vol. Symfony 6.4 l'a retiré.

La remplaçante s'appelle PrestaShopAdminController, et elle impose une autre discipline : le contrôleur devient un service déclaré, ses dépendances arrivent par le constructeur, et les services occasionnels passent par getSubscribedServices(). C'est plus propre. C'est aussi une réécriture, pas un remplacement de nom.

Les annotations deviennent des attributs

@AdminSecurity et consorts passent en attributs PHP natifs. La transformation est mécanique, mais elle touche chaque méthode de chaque contrôleur.

Les dépendances retirées du cœur

PrestaShop 9 a fait le ménage. Si votre module s'appuyait sur une de ces briques parce qu'elle était là, elle n'y est plus :

• Guzzle, remplacé par le client HTTP de Symfony
• SwiftMailer, remplacé par Symfony Mailer
• Tactician, remplacé par Symfony Messenger
• plusieurs composants Symfony que le cœur ne tire plus : Inflector, Workflow, Uid, Notifier…

Rien n'interdit de les déclarer soi-même dans le composer.json du module. Mais il faut l'avoir vu venir plutôt que de le découvrir sur une boutique en production.

Le contexte hérité

Context::$cookie n'est plus l'endroit où ranger ses données. La session Symfony prend le relais. Et de nouveaux services contextuels — EmployeeContext, ShopContext, CurrencyContext, LanguageContext — remplacent progressivement le vieux contexte global.

Ce qui ne bouge pas

C'est la bonne nouvelle, et elle est instructive : un module qui n'a aucun contrôleur Symfony ne craint presque rien. Un module bâti sur les hooks classiques, avec ses templates et sa configuration, traverse 1.7, 8 et 9 sans réécriture.

J'en ai la preuve dans mes propres modules. Celui qui filtre le spam du formulaire de contact couvre 1.7.6 à 9.x, et ce n'est pas un exploit : il n'a simplement pas de contrôleur d'administration. Ceux qui en ont un demandent tous le même travail.

La bonne façon de s'y prendre

Inventoriez d'abord. Une commande suffit à savoir à quoi vous vous exposez : cherchez FrameworkBundleAdminController dans vos modules. Chaque résultat est un contrôleur à reprendre, chaque module sans résultat est un module qui passera tout seul.

Ensuite, ne cherchez pas le code unique qui marcherait partout. C'est le sujet d'un autre billet, mais la conclusion tient en une phrase : deux branches coûtent moins cher qu'une couche de compatibilité.