Compatibilité PrestaShop 9 : Tous nos modules sont prêts

PrestaShop 9 est arrivé. Votre pile de modules est-elle prête ?

PrestaShop 9 est sorti avec la refonte architecturale la plus significative depuis que la plateforme a adopté Symfony dans sa version 1.7. J'ai préparé nos modules pour cette version depuis les premières builds alpha, et au cours de ce processus, j'ai appris exactement ce qui casse, ce qui se dégrade silencieusement, et ce que les propriétaires de boutiques doivent vérifier avant même de penser à cliquer sur « Mettre à jour ».

Ce n'est pas un résumé du changelog. C'est le guide pratique que j'aurais aimé avoir quand j'ai ouvert pour la première fois une beta de PrestaShop 9 et que j'ai regardé la moitié des modules tiers de ma boutique de test générer des erreurs 500. Que vous soyez un propriétaire de boutique évaluant votre pile de modules, un développeur freelance préparant une migration client, ou une agence gérant des dizaines d'installations PrestaShop, ce guide vous accompagne dans le processus complet d'audit de compatibilité.

Ce qui a réellement changé dans PrestaShop 9 (et pourquoi cela casse des choses)

Avant de pouvoir auditer vos modules, vous devez comprendre ce que PrestaShop 9 a changé au niveau architectural. Ce ne sont pas des mises à jour cosmétiques. Ce sont des changements fondamentaux qui touchent chaque module interagissant avec le back office, la couche base de données ou le thème front-end.

Symfony 6.4 : Le changement majeur

PrestaShop est passé de Symfony 4.4 à Symfony 6.4. Ce n'est pas une mise à jour incrémentale. C'est un saut à travers deux versions majeures de Symfony, chacune ayant introduit son propre lot de dépréciations et suppressions. Pour les développeurs de modules, la conséquence la plus critique est le fonctionnement des contrôleurs.

Avec Symfony 4.4, vous pouviez utiliser $this->get('service_name') dans les contrôleurs pour récupérer n'importe quel service depuis le conteneur. Avec Symfony 6.4, les contrôleurs doivent être définis comme des services avec une injection de dépendances appropriée. L'ancien FrameworkBundleAdminController fonctionne encore dans PrestaShop 9, mais il est officiellement déprécié et sera supprimé dans PrestaShop 10. Tout module qui étend cette classe vit sur du temps emprunté.

Ce que cela signifie pour vous : si les pages d'administration d'un module fonctionnent aujourd'hui sur PrestaShop 9 mais utilisent le modèle de contrôleur legacy, elles pourraient cesser de fonctionner complètement sur PrestaShop 10. Vous voulez des modules qui ont déjà migré vers PrestaShopAdminController avec injection par constructeur.

Bibliothèques supprimées dont vous dépendez probablement

PrestaShop 9 a supprimé plusieurs bibliothèques de son cœur que les modules utilisaient auparavant gratuitement :

• Guzzle HTTP client a été remplacé par le client HTTP Symfony. Tout module effectuant des appels API externes via Guzzle générera une erreur fatale « class not found » à moins qu'il n'inclue sa propre copie.
• SwiftMailer a été remplacé par Symfony Mailer. Les modules qui envoient des e-mails directement (notifications de commande, alertes, rapports) doivent utiliser la nouvelle interface mailer.
• Tactician command bus a été remplacé par Symfony Messenger. Les modules utilisant des patterns CQRS avec Tactician nécessitent une réécriture complète de leur gestion de commandes/requêtes.

L'aspect sournois : ces défaillances ne se manifestent pas toujours immédiatement. Un module peut s'installer et afficher sa page de configuration parfaitement, mais planter au moment où il essaie d'envoyer une requête HTTP ou de dispatcher une commande. Vous ne détecterez pas cela lors d'un test rapide « est-ce que ça s'installe ? ».

33 hooks ont été supprimés

PrestaShop 9 a supprimé 33 hooks. Ce n'est pas une erreur de frappe. Trente-trois points d'intégration sur lesquels les modules s'appuyaient n'existent tout simplement plus. Les suppressions se répartissent en trois catégories :

• Hooks de la page produit legacy (l'intégralité de l'ancienne interface d'édition de produit a été supprimée, emportant tous ses hooks) : actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before et actionAdminSortAfter/Before
• Hooks du contrôleur de connexion (maintenant gérés par la sécurité Symfony) : actionAdminLoginControllerBefore, actionAdminLoginControllerLoginBefore/After, actionAdminLoginControllerForgotBefore/After et actionAdminLoginControllerResetBefore/After
• Hooks de mise en page liés à l'ancien cycle de vie d'AdminController (initHeader, initContent, initFooter, display) sont effectivement morts car PrestaShop 9 gère la mise en page via les composants Twig

Si un module s'enregistre sur l'un de ces hooks, il ne plantera pas, mais le hook ne se déclenchera tout simplement jamais. Le module perd silencieusement des fonctionnalités. C'est sans doute pire qu'un plantage car vous pourriez ne pas remarquer pendant des semaines qu'une fonctionnalité a cessé de fonctionner.

PHP 8.1 minimum, PHP 8.4 recommandé

PrestaShop 9 nécessite PHP 8.1 au minimum. Cela élimine les boutiques fonctionnant encore sous PHP 7.4 ou 8.0. Plus important, cela signifie que les modules doivent gérer les fonctionnalités de PHP 8.1+ et la vérification de type plus stricte. Les fonctions qui retournaient auparavant des types mixtes nécessitent maintenant des déclarations de type de retour explicites. Les paramètres nullables nécessitent le préfixe ? ou les types union. L'ère du typage souple en PHP est révolue.

Je teste tous nos modules avec PHP 8.1, 8.2, 8.3 et 8.4 spécifiquement parce que chaque version mineure de PHP introduit de nouveaux avis de dépréciation qui peuvent remplir vos logs et, dans les environnements de rapport d'erreurs strict, provoquer des avertissements visibles pour les clients.

Gestion avancée des stocks : disparue

L'intégralité du système de gestion avancée des stocks a été supprimée de PrestaShop 9. Cela inclut les commandes fournisseurs, les entrepôts et l'ancienne interface de gestion des stocks. Si l'un de vos modules interagit avec les données d'entrepôt, les hooks de commandes fournisseurs ou l'API de gestion avancée des stocks, il cassera. Cette suppression affecte également les tables de base de données, donc les modules interrogeant directement les tables liées aux stocks obtiendront des erreurs SQL.

Dépréciation du singleton Context

Le singleton Context que chaque développeur PrestaShop connaît et apprécie (ou tolère) est en cours de suppression progressive. PrestaShop 9 a introduit des services de contexte dédiés : EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext et d'autres. Les modules utilisant Context::getContext() fonctionnent encore, mais les modules construits selon les pratiques modernes devraient faire la transition vers ces services dédiés.

La fonction de traduction n'échappe plus le HTML

C'est un changement subtil mais dangereux. La fonction trans() dans PrestaShop 9 n'échappe plus automatiquement les entités HTML. Dans les versions précédentes, passer du contenu utilisateur à travers trans() fournissait une couche de protection XSS presque par accident. Dans PrestaShop 9, les modules doivent utiliser explicitement htmlspecialchars() sur tout contenu dynamique passé aux traductions. Les modules qui ne mettent pas cela à jour introduisent potentiellement des vulnérabilités de sécurité.

Thème Hummingbird et Bootstrap 5

PrestaShop 9 est livré avec le thème Hummingbird par défaut, construit sur Bootstrap 5. PrestaShop 9.1 a ensuite été mis à jour vers Bootstrap 5.3.3. Pour tout module affichant des templates front-end, cela signifie :

• Les noms de classes Bootstrap 4 ne fonctionnent plus (par ex., .no-gutters devient .g-0, .custom-checkbox devient .form-check)
• Les attributs data sont préfixés (data-toggle devient data-bs-toggle)
• jQuery est officiellement déprécié dans Hummingbird et sera supprimé dans la prochaine version majeure du thème. Les modules s'appuyant sur jQuery pour les fonctionnalités front-end ont besoin d'un plan de migration vers du JavaScript natif
• Les sélecteurs CSS basés sur les classes spécifiques à PrestaShop sont remplacés par des attributs data data-ps-*

Comment auditer vos modules installés : un processus étape par étape

Maintenant que vous comprenez ce qui a changé, voici le processus systématique que j'utilise pour évaluer la compatibilité des modules. Vous n'avez pas besoin d'être développeur pour suivre la plupart de ces étapes.

Étape 1 : Inventoriez vos modules

Allez dans votre back office PrestaShop, naviguez vers Modules > Gestionnaire de modules, et exportez ou capturez votre liste complète de modules installés. Pour chaque module, notez :

• Nom du module et version actuelle
• Nom du fournisseur/développeur
• Date de dernière mise à jour
• S'il s'agit d'un module gratuit, d'un module payant de PrestaShop Addons ou d'un module tiers

Catégorisez chaque module selon son caractère critique pour votre activité. Un module de passerelle de paiement est critique. Un widget de partage social est un plus. Cette priorisation détermine votre calendrier de mise à jour.

Étape 2 : Vérifiez les déclarations de compatibilité des fournisseurs

Pour chaque fournisseur de modules, recherchez une déclaration explicite de compatibilité PrestaShop 9. Voici ce qu'il faut chercher et quels sont les signaux d'alerte :

Signaux positifs :

• Le fournisseur a un article de blog ou une entrée de changelog mentionnant spécifiquement la compatibilité PrestaShop 9.0 et 9.1
• La version du module a été mise à jour après la date de sortie de PrestaShop 9
• Le fournisseur mentionne des tests avec Symfony 6.4 et PHP 8.1+
• La rétrocompatibilité avec PrestaShop 8.x est maintenue (montre qu'ils comprennent le support multi-versions)

Signaux d'alerte :

• Aucune mention de PrestaShop 9 nulle part sur le site du fournisseur
• La dernière mise à jour du module date d'avant les versions alpha de PrestaShop 9
• Les autres modules du fournisseur n'ont pas été mis à jour non plus (suggère une gamme de produits abandonnée)
• La description du module mentionne « Compatible PrestaShop 1.7 » sans aucune référence 8.x ou 9.x

Étape 3 : Inspectez le code du module pour les patterns problématiques connus

Si vous avez des connaissances basiques en PHP, ou que votre développeur en a, ouvrez les fichiers du module et recherchez ces patterns spécifiques qui causeront assurément des problèmes sur PrestaShop 9 :

Recherchez $this->get( dans les contrôleurs admin — C'est le pattern legacy d'accès aux services de Symfony 4.4. Il fonctionne sur PrestaShop 9 mais est déprécié. Les modules utilisant cela n'ont pas été modernisés.

Recherchez use GuzzleHttp — Si le module importe Guzzle mais ne l'inclut pas dans son propre répertoire vendor, il cassera sur PrestaShop 9 où Guzzle a été supprimé du cœur.

Recherchez Swift_ ou SwiftMailer — Même situation. SwiftMailer a été supprimé du cœur.

Recherchez Tools::displayPrice — Ceci est déprécié. Les modules devraient utiliser le service Locale pour le formatage des prix.

Recherchez data-toggle= dans les fichiers .tpl — Attributs data Bootstrap 4. Ceux-ci devraient être data-bs-toggle= pour la compatibilité Hummingbird.

Recherchez $.ajax ou $(document) dans les fichiers .js — Utilisation de jQuery. Fonctionne encore sur le thème Classic mais cassera sur Hummingbird quand jQuery sera supprimé.

Étape 4 : Mettez en place un environnement de staging

Ne testez jamais la compatibilité des modules sur votre boutique en production. Voici la configuration minimale de staging :

1. Clonez votre base de données de production vers une base de données séparée (ou utilisez la fonctionnalité de staging de votre hébergeur)
2. Installez PrestaShop 9 en installation fraîche ou utilisez le module de mise à jour sur votre installation clonée
3. Installez vos modules un par un, en vérifiant le log d'erreurs après chaque installation. L'ordre est important : installez d'abord les modules de paiement et d'expédition, puis les modules SEO, puis les modules cosmétiques
4. Testez les fonctionnalités principales de chaque module, pas seulement « est-ce que la page de configuration se charge ». Passez une commande test. Lancez un import de produits. Générez un sitemap. Tout ce que le module fait réellement en production

Astuce de pro : Vérifiez votre log d'erreurs PHP (/var/log/php_errors.log ou le log d'erreurs de votre hébergeur) après chaque installation de module. De nombreux problèmes de compatibilité apparaissent sous forme d'avis de dépréciation ou d'avertissements PHP plutôt que de plantages francs. L'avertissement d'aujourd'hui est l'erreur fatale de demain.

Étape 5 : Testez le rendu front-end sur les deux thèmes

Si vous utilisez PrestaShop 9 avec le nouveau thème Hummingbird, testez chaque module qui affiche quoi que ce soit en front-end. Portez une attention particulière à :

• Les modifications de la page de commande (formulaires de modules de paiement, sélection du transporteur, validation d'adresse)
• Les widgets de page produit (avis, listes de souhaits, guides des tailles, champs personnalisés)
• Les hooks d'en-tête et de pied de page (méga menus, barres de recherche, aperçus du panier)
• Les filtres et le tri des pages catégorie

Si vous restez sur le thème Classic, votre risque de compatibilité front-end est plus faible, mais les changements Bootstrap 5 peuvent toujours affecter les modules qui injectent leur propre CSS.

Ce qu'il faut demander à vos fournisseurs de modules

Lorsque vous contactez un fournisseur de modules au sujet de la compatibilité PrestaShop 9, ne demandez pas simplement « est-il compatible ? ». Cette question vous donne une réponse oui/non qui pourrait être fausse. Posez plutôt ces questions spécifiques :

1. « Le module a-t-il été testé sur PrestaShop 9.0 ET 9.1 ? » — La version 9.1 a introduit des changements cassants supplémentaires (Bootstrap 5.3.3, dépréciation de jQuery, nouvelles modifications de hooks). Tester uniquement sur 9.0 ne suffit pas.
2. « Le module supporte-t-il encore PrestaShop 8.x avec le même fichier ZIP ? » — Si le fournisseur exige une version séparée pour PrestaShop 9, c'est une charge de maintenance pour vous. Un module bien construit gère la détection de version en interne.
3. « Avez-vous migré les patterns dépréciés de Symfony 4.4 ? » — Si le fournisseur ne comprend pas cette question, cela vous dit quelque chose sur sa profondeur technique.
4. « Le module utilise-t-il jQuery en front-end ? » — Si oui, renseignez-vous sur leur calendrier de migration vers du JavaScript natif avant que Hummingbird ne supprime le support jQuery.
5. « Quelle est votre plage de test de versions PHP ? » — Vous voulez entendre 8.1 à 8.4, pas juste « PHP 8 ».

Le cadre de décision pour la mise à jour

Sur la base de mon expérience de mise à jour d'environnements de test et d'aide aux propriétaires de boutiques pour évaluer leur état de préparation, voici un cadre pratique pour décider quand mettre à jour :

Mettez à jour maintenant si :

• Tous vos modules ont une compatibilité PrestaShop 9 confirmée par leurs fournisseurs
• Vous utilisez déjà PHP 8.1+
• Vous avez un environnement de staging où vous avez testé le chemin de mise à jour complet
• Votre thème est soit Classic, Hummingbird, ou un thème enfant de l'un des deux

Attendez 3 à 6 mois si :

• Un ou deux modules non critiques n'ont pas de confirmation de compatibilité
• Votre thème est un thème tiers fortement personnalisé (les fournisseurs de thèmes ont souvent du retard sur le support des versions majeures)
• Vous vous appuyez sur la gestion avancée des stocks (vous devez d'abord trouver des workflows de remplacement)

Ne mettez pas à jour pour l'instant si :

• Des modules critiques (paiement, expédition, intégration ERP) n'ont aucune déclaration de compatibilité PrestaShop 9
• Vous utilisez PHP 7.4 ou 8.0 (vous avez d'abord besoin d'une mise à jour PHP, qui est un projet à part entière)
• Votre fournisseur de modules est silencieux depuis plus d'un an (le module est peut-être abandonné)

Comment nous avons préparé nos modules (une étude de cas réelle)

Chez mypresta.rocks, j'ai commencé à tester avec les builds alpha de PrestaShop 9 des mois avant la version stable. Voici à quoi le processus a réellement ressemblé, car je pense que c'est instructif pour comprendre ce que « compatible » signifie vraiment.

Phase 1 : Analyse de compatibilité automatisée

J'ai exécuté une analyse statique sur chaque module en recherchant les patterns décrits ci-dessus : utilisation de contrôleurs legacy, imports de bibliothèques supprimées, appels de fonctions dépréciées, classes Bootstrap 4 dans les templates et utilisation de jQuery dans les fichiers JavaScript. Cela a produit une liste priorisée de changements requis.

Phase 2 : Migration Symfony 6.4

Chaque contrôleur admin a été examiné pour les patterns d'accès au conteneur de services. Là où les modules utilisaient $this->get(), nous avons migré vers l'injection par constructeur. Là où les modules étendaient le contrôleur de base déprécié, nous avons mis à jour la classe parente. C'était la phase la plus chronophage car elle touche l'architecture centrale de chaque module côté administration.

Phase 3 : Audit des hooks

Nous avons croisé chaque enregistrement de hook dans chaque module avec la liste des 33 hooks supprimés. Là où les modules utilisaient des hooks supprimés, nous avons soit migré vers des hooks de remplacement, soit implémenté un enregistrement conditionnel de hooks basé sur la version qui utilise automatiquement le bon hook pour la version PrestaShop détectée.

Phase 4 : Tests multi-versions

Chaque module a été testé sur PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 et 9.1. Sur chaque version, nous avons testé avec PHP 8.1, 8.2, 8.3 et 8.4. Un seul fichier ZIP de module fonctionne sur toutes ces combinaisons car le module détecte la version de PrestaShop à l'exécution et adapte son comportement en conséquence.

C'est ce que « rétrocompatible » signifie réellement en pratique. Ce n'est pas deux builds séparées. C'est une seule base de code qui gère les différences de version en interne.

Phase 5 : Tests des thèmes front-end

Chaque module avec un rendu front-end a été testé sur le thème Classic et le thème Hummingbird. Les noms de classes Bootstrap, les attributs data et le JavaScript ont été vérifiés sur les deux. Là où des différences de template étaient nécessaires, nous avons utilisé la détection de version intégrée de PrestaShop pour charger le template approprié.

Le résultat : tous les modules mypresta.rocks sont entièrement compatibles avec PrestaShop 9.0 et 9.1, tout en maintenant la rétrocompatibilité avec PrestaShop 1.7.6+ et toutes les versions 8.x. Pas de téléchargements séparés, pas d'étapes d'installation spéciales, pas de tarification « édition PrestaShop 9 ».

Problèmes courants après la mise à jour et comment les résoudre

Même avec des modules compatibles, vous pourriez rencontrer ces problèmes après la mise à jour vers PrestaShop 9 :

Écran blanc / Erreur 500 après l'installation d'un module

Généralement causé par une dépendance Composer manquante. Vérifiez votre log d'erreurs PHP pour les erreurs « Class not found ». La solution est soit de mettre à jour le module (si le fournisseur a une nouvelle version) soit d'ajouter manuellement la bibliothèque manquante dans le répertoire vendor du module.

Les pages d'administration se chargent mais des fonctionnalités manquent

C'est le problème de suppression silencieuse des hooks. Le module s'est installé avec succès, mais ses hooks ne se déclenchent plus sur PrestaShop 9. Vérifiez les enregistrements de hooks du module par rapport à la liste des hooks supprimés. Contactez le fournisseur pour une version mise à jour qui utilise les hooks de remplacement.

Style front-end cassé sur Hummingbird

Changements de noms de classes de Bootstrap 4 à 5. Le module fonctionne sur Classic mais semble cassé sur Hummingbird. Cela nécessite des mises à jour de templates de la part du fournisseur du module. En solution temporaire, vous pouvez basculer sur le thème Classic en attendant que le fournisseur mette à jour.

Erreurs JavaScript dans la console du navigateur

Souvent causées par une dépendance à jQuery dans un environnement Hummingbird. Vérifiez la console développeur du navigateur (F12) pour les erreurs « $ is not defined » ou « jQuery is not defined ». La solution à long terme est le JavaScript natif, mais à court terme, vous pouvez inclure jQuery manuellement dans les assets de votre thème.

Les notifications par e-mail ont cessé de fonctionner

Si un module envoie des e-mails via SwiftMailer directement au lieu de la fonction mail de PrestaShop, il cassera sur PrestaShop 9 où SwiftMailer a été remplacé par Symfony Mailer. Contactez le fournisseur pour une mise à jour.

PrestaShop 9.1 : Changements supplémentaires à surveiller

PrestaShop 9.1 a introduit son propre lot de changements en plus de 9.0. Si vous mettez à jour directement vers 9.1 (recommandé, car c'est la dernière version stable), soyez conscient de ces facteurs de compatibilité supplémentaires :

• Theme::getDefaultTheme() ne retourne plus la chaîne codée en dur « classic ». Les modules qui supposaient que le thème par défaut est Classic doivent être mis à jour.
• Le hook displaySearch a été supprimé de Hummingbird car il causait des conflits sur les pages 404. Les modules qui s'accrochent à displaySearch pour la personnalisation de la recherche front-end doivent utiliser des hooks alternatifs.
• Les bibliothèques de graphiques D3 et NVD3 ont été mises à jour vers de nouvelles versions. Les widgets de tableau de bord utilisant ces bibliothèques peuvent s'afficher incorrectement.
• Les sélecteurs JavaScript ont migré vers la convention data-ps-*, remplaçant les sélecteurs basés sur les classes. Les modules utilisant querySelector avec des noms de classes spécifiques à PrestaShop peuvent ne plus cibler les bons éléments.

Votre checklist avant la mise à jour

Imprimez ceci, collez-le au mur, et ne mettez pas à jour tant que chaque point n'est pas coché :

1. Inventoriez tous les modules installés avec les noms des fournisseurs et les versions actuelles
2. Vérifiez le site web de chaque fournisseur pour les déclarations de compatibilité PrestaShop 9
3. Mettez à jour tous les modules vers leurs dernières versions (même avant de mettre à jour PrestaShop)
4. Mettez en place un environnement de staging avec une copie de votre base de données de production
5. Installez PrestaShop 9.1 sur le staging
6. Installez les modules un par un, en vérifiant les logs d'erreurs après chacun
7. Testez les fonctionnalités principales de chaque module (pas seulement « est-ce que la page de config se charge »)
8. Testez le rendu front-end sur votre thème actif
9. Passez une commande test complète à travers le processus de paiement
10. Vérifiez les logs d'erreurs PHP pour les avertissements de dépréciation
11. Vérifiez l'envoi d'e-mails depuis tous les modules qui envoient des notifications
12. Sauvegardez tout : base de données, fichiers et configuration
13. Planifiez la mise à jour pendant les heures de faible trafic
14. Conservez votre sauvegarde PrestaShop 8.x disponible pendant au moins 30 jours après la mise à jour

Réflexions finales

PrestaShop 9 est une amélioration significative. Symfony 6.4 apporte de meilleures performances, des pratiques PHP modernes et une architecture plus maintenable. Le thème Hummingbird est plus rapide et plus accessible que Classic. La nouvelle API admin ouvre des possibilités qui n'étaient pas disponibles auparavant.

Mais rien de tout cela n'a d'importance si vos modules cassent pendant la mise à jour. Prenez le temps d'auditer correctement. Utilisez un environnement de staging. Exigez de vos fournisseurs des déclarations de compatibilité explicites, pas des réponses vagues du type « ça devrait marcher ».

Si vous recherchez des modules rigoureusement testés de PrestaShop 1.7.6 à 9.1, jetez un œil au catalogue de modules mypresta.rocks. Chaque module est livré sous forme d'un seul fichier ZIP fonctionnant sur toutes les versions supportées, et la compatibilité PrestaShop 9 est incluse avec chaque licence, sans être vendue comme une mise à jour séparée.

Vous avez des questions sur votre scénario de mise à jour spécifique ? Contactez-nous et je vous aiderai à évaluer votre pile de modules.