Module cassé après la mise à jour vers PrestaShop 9 : diagnostic et correction
Après le passage à PrestaShop 9, une page du back-office reste blanche, un module ne s'installe plus, les courriels ne partent plus, ou un réglage a disparu. PrestaShop 9 change en profondeur la base technique sur laquelle reposent les modules : ce qui fonctionnait en version 8 peut s'arrêter sans message d'erreur clair.
Nous trouvons la cause sur une copie de votre boutique, puis nous corrigeons le module, le remplaçons ou adaptons la configuration, avant de remettre la boutique en production.
Les symptômes
- La page Modules ou la page Traductions du back-office reste blanche, ou renvoie une erreur 500. Une cause décrite : un module présent en base mais absent ou incomplet sur le disque, ou copié depuis une boutique en version 8, que PrestaShop 9 analyse même désactivé (source).
- Un module refuse de s'installer, ou s'installe à moitié : il apparaît dans la liste, mais son onglet ou ses réglages manquent.
- Les courriels de commande ne partent plus depuis la mise à jour.
- Un module qui ajoutait des champs à la fiche produit n'affiche plus rien.
- Une fonction a disparu : gestion avancée des stocks, livraison à plusieurs adresses, quantités de personnalisation.
- Le front-office fonctionne, mais une page d'administration d'un module ne s'ouvre plus.
Ce qui change en PrestaShop 9, et ce que cela casse
D'après la documentation officielle des changements de la version 9.0 :
| Changement | Ce que cela peut casser |
|---|---|
| PHP 8.1 au minimum | Un module écrit pour une version ancienne de PHP peut s'arrêter sur une erreur fatale. |
| Symfony passe de la version 4.4 à la 6.4 | Les pages d'administration des modules écrites avec Symfony, et les appels du type $this->get('service') dans leurs contrôleurs. |
| Guzzle et SwiftMailer ne sont plus fournis par PrestaShop | Un module qui s'en servait pour appeler un service extérieur ou envoyer des courriels. |
| Chiffrement SSL retiré de l'envoi des courriels : TLS ou aucun | Une configuration d'envoi réglée en SSL. |
Ancienne page produit supprimée, avec ses hooks actionAdminProductsController* | Les modules qui ajoutaient des onglets ou des champs à l'ancienne fiche produit. |
| Hooks de la page de connexion du back-office supprimés | Les modules de sécurité ou de double authentification qui s'y accrochaient. |
| Gestion avancée des stocks, livraison multi-adresses, quantités de personnalisation supprimées | Les boutiques et les modules qui en dépendaient. |
trans() n'échappe plus les textes | Des textes mal affichés, ou un risque d'injection si le module comptait sur cet échappement. |
| Doctrine DBAL passe en version 3, jQuery mis à jour | Des requêtes et des scripts d'administration écrits pour les anciennes versions. |
| Fichiers PHP sensibles interdits dans les dossiers de modules | Un module qui exposait un script PHP directement, au lieu d'un contrôleur de module. |
À l'inverse, tout n'a pas disparu : AdminController, ModuleAdminController et HelperForm sont toujours présents pour les pages anciennes. Un module qui ne s'appuie que sur eux peut continuer à fonctionner sans modification.
Ce que nous avons constaté nous-mêmes
- Notre module Bot Radar est installé sur une boutique en production sous PrestaShop 9.0 : ses pages d'administration, écrites avec
ModuleAdminControlleretHelperForm, fonctionnent sans modification. - En PrestaShop 9, installer un module depuis un simple script PHP échoue au milieu de l'installation (le conteneur Symfony n'est pas chargé) et le laisse à moitié installé : présent en base, sans hook ni onglet. L'installation par la console de PrestaShop (
bin/console prestashop:module install) fait tout correctement. C'est aussi la façon de réparer.
Comment nous intervenons
- Vous décrivez le problème : ce qui ne marche plus, depuis quand, la version de PrestaShop et de PHP.
- Diagnostic sur une copie de la boutique, jamais directement en production : journaux, modules installés, cohérence entre la base et les fichiers.
- Une estimation avant d'aller plus loin : correction du module, remplacement par un module compatible, ou réglage de la configuration.
- Correction et essai sur la copie, puis mise en production avec votre accord, et un compte rendu de ce qui a été fait.
Avant une mise à jour, le même travail sert d'audit : la liste de vos modules et, pour chacun, ce qui risque de casser en PrestaShop 9.
80 € / heure
Minimum une heure, puis par tranche de 30 minutes. Le diagnostic est facturé au temps passé ; la suite fait l'objet d'une estimation que vous validez. Un module réécrit ou développé pour vous est chiffré au forfait, de 490 € à 1 490 €.
Questions fréquentes
Pouvez-vous corriger un module acheté sur PrestaShop Addons ?
Cela dépend de sa licence et de son éditeur. Le premier réflexe est de vérifier si l'éditeur publie une version compatible avec PrestaShop 9 ; sinon, nous regardons si une correction est permise ou s'il vaut mieux remplacer le module.
Travaillez-vous directement sur ma boutique en ligne ?
Non : le diagnostic et les corrections se font sur une copie. La boutique en production n'est modifiée qu'à la fin, avec votre accord.
Faut-il revenir à PrestaShop 8 ?
Un retour en arrière est possible à partir d'une sauvegarde faite avant la mise à jour, mais il fait perdre les commandes passées depuis. Corriger ce qui bloque en version 9 évite cette perte ; le diagnostic permet de choisir entre les deux.
Combien de temps faut-il ?
Cela dépend de la cause. Le diagnostic donne une estimation avant tout travail supplémentaire.