Migrer PrestaShop 1.7 vers 8 et 9 : ce qui casse et comment s’y préparer
La mise à jour de PrestaShop 1.7 vers 8 ou 9 casse rarement le cœur lui-même. Ce qui casse, ce sont les modules, les overrides, le thème et tout ce qui a été ajouté « vite fait » au fil des années. Ce guide s’appuie sur de vraies migrations de boutiques de 1.7 vers 8.1 : quoi vérifier avant de commencer, ce qui cesse généralement de fonctionner, dans quel ordre procéder et quoi tester ensuite.
Les versions de PHP tracent le chemin
| PrestaShop | PHP pris en charge |
|---|---|
| 1.7.8 | 7.1 – 7.4 |
| 8.0 – 8.2 | 7.2.5 – 8.1 (8.1 recommandé) |
| 9.0 | 8.1 – 8.4 |
En pratique : PrestaShop 1.7.8 ne tourne pas sous PHP 8, et PrestaShop 9 ne tourne pas sous PHP 7. L’ordre habituel consiste à mettre la boutique à jour en 8.x sous PHP 7.4, puis seulement à passer PHP en 8.1. On passe en 9 depuis la 8.x, déjà sous PHP 8.1 ou plus récent – ou bien on fait une installation propre de la 9 et on migre les données. Chaque saut de PHP est un test séparé de tous les modules.
Avant de commencer : l’inventaire
-- version de la boutique enregistrée en base
SELECT value FROM ps_configuration WHERE name = 'PS_VERSION_DB';
-- modules installés et leurs versions
SELECT name, version, active FROM ps_module ORDER BY active DESC, name;# overrides de classes et de contrôleurs – chacun doit être vérifié
find override -name '*.php' ! -name 'index.php'
# fonctions supprimées en PHP 8, dans les modules et les thèmes
grep -rlE 'create_function|each\(|mysql_query|\$[a-zA-Z_]+\{[0-9]' modules themes --include=*.php | head -50Faites un tableau des résultats : module, fournisseur, existence d’une version pour PrestaShop 8/9, utilité réelle. À ce stade, on découvre souvent que 20 à 30 % des modules peuvent simplement être supprimés.
Ce qui casse le plus souvent
| Domaine | Ce qui se passe | Que faire |
|---|---|---|
| Modules écrits pour PHP 7 | Erreur fatale après le changement de PHP : fonctions supprimées, typage plus strict, changements dans la gestion des tableaux et des chaînes | Nouvelle version de l’auteur ou correction du code ; modules non maintenus – à remplacer |
| Overrides | Les classes du cœur ont reçu des types de retour et des signatures modifiées en 8.0 – un ancien override provoque une erreur fatale | Réécrire en hooks ou adapter les signatures ; beaucoup d’overrides se remplacent par un hook |
Classe Attribute | Renommée ProductAttribute en 8.0 | Corriger les références dans les modules et overrides |
| Thème | Infobulles jQuery UI, identifiants modifiés à l’étape de paiement, thème enfant qui charge les ressources du parent | Tester le tunnel de commande étape par étape ; dans un thème enfant, vérifier use_parent_assets |
| Fiche produit du back-office | Depuis la 8.1, la nouvelle fiche produit est activée par défaut sur les nouvelles installations ; lors d’une mise à jour, elle s’active dans « Fonctionnalités nouvelles et expérimentales » | Vérifier les modules qui ajoutent des champs à l’édition produit avant de l’activer |
| Imports et intégrations | Les mots de passe clients et employés doivent être enregistrés hachés – les scripts qui inséraient des mots de passe en clair ne fonctionnent plus | Corriger les scripts d’import et les intégrations ERP |
| Passerelles de paiement et transporteurs | Les anciennes versions des modules ne fonctionnent pas ou ont des failles non corrigées | Dernières versions des prestataires, test de chaque méthode |
En plus pour PrestaShop 9
- Symfony 6.4 et PHP 8.1+. Les modules avec une partie back-office importante (contrôleurs Symfony, formulaires, Twig) demandent une version pour la 9.
- L’accès direct aux fichiers
.phprenvoie une erreur 403. Cela touche des « raccourcis » courants dans les modules :ajax.php,cron.php, flux XML maison. Ce code doit passer dans des contrôleurs de module (ModuleFrontController,ModuleAdminController), et les URL des crons et des flux doivent être changées partout où elles sont utilisées. - Le mode debug ne s’active que pour un visiteur disposant d’un cookie précis – pratique pour tester en production, à condition de le savoir.
- Hummingbird, le nouveau thème, n’est pas celui par défaut. Migrer en 9 n’oblige pas à changer de thème.
Un ordre qui fonctionne
- Une copie de la boutique sur un sous-domaine de test (fichiers et base), avec les e-mails clients désactivés et les paiements en mode test.
- Le ménage : désinstallez les modules inutilisés et supprimez les overrides superflus dès la 1.7.
- La mise à jour du cœur avec le module de mise à jour (1-Click Upgrade) ou une installation propre avec migration des données – pour les boutiques très modifiées, la seconde option est souvent plus rapide.
- Le passage de PHP et les corrections de modules jusqu’à des journaux (
var/logs) sans erreur. - Les tests de la liste ci-dessous, puis un gel des modifications en production et la bascule.
Tests après migration
- Une commande avec chaque moyen de paiement et de livraison, les e-mails au client et à la boutique, les factures.
- Compte client : inscription, connexion avec un ancien mot de passe, réinitialisation.
- URL des produits et catégories inchangées – ou redirections 301.
- Crons, flux produits, intégrations ERP et transporteurs.
- Index de recherche et régénération des miniatures.
- Back-office : édition d’un produit avec déclinaisons, commandes, retours.
Une migration PrestaShop sans interruption
Chez CodeTheWeb, nous migrons PrestaShop 1.7 vers 8 et 9 : inventaire des modules, réécriture des overrides en hooks, adaptation des modules sur mesure à PHP 8 et Symfony, tests sur une copie et bascule en production. Décrivez-nous votre boutique – nous répondrons avec un plan et une estimation.
Vous hésitez encore à mettre à jour ? Lisez : PrestaShop 1.7 en 2026 : rester ou mettre à jour.