Modules PrestaShop incompatibles après une migration
Un module qui tournait sans problème depuis des années peut disparaître silencieusement ou planter net après une migration PrestaShop. Ce n’est presque jamais un hasard : il y a toujours un mécanisme technique précis derrière, et il se vérifie avant de migrer.
Comment un module déclare sa compatibilité
Chaque module PrestaShop déclare la plage de versions avec laquelle il fonctionne dans son fichier config.xml, via les balises <compatibility><min> et <max>. La même information existe aussi dans la classe PHP principale du module, sous la forme de la propriété $ps_versions_compliancy. C’est sur cette déclaration que se base le marketplace officiel Addons pour indiquer si un module est proposé comme compatible avec une version donnée : si le module n’a jamais été mis à jour pour couvrir la version cible, il n’apparaît simplement plus comme disponible pour elle.
Cette déclaration ne garantit pas à elle seule que le module fonctionnera réellement : elle indique l’intention de l’éditeur, pas le résultat d’un test exhaustif. Mais son absence est un signal fiable : un module dont la plage de compatibilité s’arrête avant la version visée n’a de toute façon aucune chance de fonctionner correctement.
Les quatre mécanismes qui rendent un module incompatible
- Le hook de paiement a changé de nom entre PrestaShop 1.6 et 1.7 : displayPayment (1.6) est remplacé par paymentOptions (1.7, 8 et 9). Un module de paiement écrit pour 1.6 et jamais mis à jour n’apparaît simplement plus au moment de payer, sans message d’erreur : c’est une cause fréquente et sournoise de « le module a disparu ».
- Beaucoup de modules anciens utilisent une syntaxe d’accès aux tableaux ou aux chaînes avec des accolades, par exemple $array{0} au lieu de $array[0]. Cette syntaxe a été supprimée en PHP 8 et provoque une erreur fatale dès que le module tourne sur un serveur passé en PHP 8, indépendamment même de la version de PrestaShop installée.
- Le système d’override, qui remplace des fichiers du dossier override/ pour modifier une classe ou un contrôleur du cœur, casse à chaque migration majeure si la classe d’origine a changé de signature ou de structure entre les deux versions : l’override peut alors ne plus être appelé du tout, ou provoquer une erreur PHP à l’exécution.
- Un module déclaré compatible sur le papier peut malgré tout ne jamais avoir été réellement testé sur la version cible par son éditeur, en particulier pour des modules peu maintenus ou abandonnés : la déclaration de compatibilité dans config.xml reflète une intention, pas un test exhaustif.
Comment je vérifie la compatibilité avant de migrer
-
Lire le config.xml de chaque module installé
Je vérifie la plage de compatibilité déclarée dans chaque module réellement installé sur la boutique, y compris ceux qui semblent secondaires.
-
Vérifier la fiche du module sur Addons
Je consulte la page du module sur le marketplace officiel pour voir quelles versions sont annoncées comme compatibles par l’éditeur, et si une version à jour existe.
-
Tester sur une copie de la boutique
La déclaration de compatibilité ne remplace jamais un test réel. Je migre d’abord sur une copie et j’exerce chaque module dans ses fonctions principales avant de valider la bascule.
-
Relire manuellement les overrides et personnalisations
Un module ou une personnalisation qui repose sur beaucoup d’overrides demande une relecture manuelle systématique, pas seulement un test automatisé, parce qu’une erreur d’override peut rester silencieuse jusqu’à ce qu’une action précise la déclenche.
Que faire quand un module n’a pas d’équivalent officiel sur la version cible
Quand un module n’existe tout simplement pas pour la version visée, je commence par chercher un module équivalent chez un autre éditeur : la fonctionnalité en elle-même est rarement unique, même si le module précis ne l’est plus. Si aucune solution du marché ne convient, je développe un module sur mesure adapté à la nouvelle architecture, en reprenant la logique métier du module d’origine sans hériter de son code devenu obsolète.
Pages liées
-
Checklist avant une migration PrestaShop
Ce qu’il faut inventorier et sauvegarder avant de lancer une migration, quelle que soit la version de départ ou d’arrivée.
-
Passer PrestaShop à PHP 8
Ce que ça implique quand un hébergeur retire PHP 7 de son offre et que le passage à PHP 8 fait planter du code ancien.
-
Migration PrestaShop 1.6 vers 1.7
Passage à Symfony partiel, thème Classic à reconstruire, hook displayPayment disparu : ce que casse réellement le saut de 1.6 vers 1.7.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.