Migrer une boutique PrestaShop 1.7 vers la version 8
Le passage le plus courant aujourd’hui : compatibilité PHP 8, JavaScript du back-office migré en TypeScript, modules à revérifier un par un avant de lancer quoi que ce soit.
Ce qui change concrètement entre 1.7 et 8
Techniquement, le saut de 1.7 à 8 est moins radical que celui de 1.6 à 1.7 : l’architecture hybride Smarty/Symfony et le thème Classic restent en place. Ce qui change vraiment, c’est la compatibilité PHP : PrestaShop 8 demande PHP 7.2.5 au minimum, prend en charge PHP 8.0 et 8.1 dès sa sortie, puis PHP 8.2 depuis la version 8.2 (septembre 2024). Aucune version 1.7.x ne fonctionne sous PHP 8, Smarty plante immédiatement : migrer vers 8 implique donc presque toujours de monter la version PHP en même temps que PrestaShop, ce qui multiplie les points de rupture.
Côté back-office, changement plus discret mais réel : le JavaScript d’administration migre vers TypeScript dès la 8.0, et les surcharges ou scripts personnalisés développés sous 1.7 ne se branchent plus de la même façon. De nombreuses méthodes du cœur déclarent aussi un type de retour, conséquence de PHP 8.1 : un override qui ne respecte pas cette signature déclenche une erreur fatale, pas un avertissement.
La base de données change aussi de structure à chaque version majeure : nouvelles tables, colonnes renommées. Restaurer un dump SQL tel quel sur une 8 fraîche n’est pas fiable ; c’est autoupgrade qui exécute les scripts de mise à jour adaptés.
Modules et fonctions qui posent problème
- Le back-office affiche une erreur fatale au premier accès après le passage en PHP 8.1, faute de type de retour sur une méthode surchargée.
- Un module installé en 1.7 est introuvable ou grisé après la mise à jour, faute de compatibilité déclarée avec la version 8 dans config.xml.
- Un module personnalisé utilise encore la syntaxe accolades pour accéder à un tableau ou une chaîne ($array{0}), supprimée par PHP 8 : la page plante avec une erreur de syntaxe.
- Un script ou une surcharge back-office sur mesure ne s’exécute plus, à cause du passage du JavaScript d’administration au TypeScript.
- La propriété $ps_versions_compliancy d’un module, figée sur l’ancienne version, empêche son activation même si le code fonctionnerait sans modification.
Comment je mène cette migration
-
Audit PHP et modules
Je vérifie la version PHP actuelle et cible, et je liste les modules installés avec leur compatibilité déclarée dans config.xml et $ps_versions_compliancy.
-
Sauvegarde complète indépendante
Dump de la base et copie complète des fichiers avant toute intervention, en plus de la sauvegarde interne d’autoupgrade.
-
Migration sur copie de la boutique
Autoupgrade tourne d’abord sur un environnement de test : sauvegarde des fichiers et de la base, puis exécution des scripts de mise à jour de schéma.
-
Le point de non-retour : la mise à jour de la base
Une fois que les scripts de mise à jour de la base s’exécutent, revenir en arrière ne consiste plus à annuler des fichiers : seule la restauration du dump pris avant l’opération permet un retour propre. Je ne lance cette étape qu’après avoir validé fichiers et modules.
-
Correction des modules et surcharges
Je mets à jour ou remplace les modules bloqués par une compatibilité obsolète ou la syntaxe accolades supprimée en PHP 8, et j’adapte les surcharges back-office touchées par le TypeScript.
-
Bascule en production
Une fois la version de test validée, je programme la bascule à faible trafic, PHP compris, pour limiter l’impact sur les commandes en cours.
Comment je vérifie après la migration
Après la bascule, je compare commandes, clients et produits entre ancienne et nouvelle base pour vérifier qu’aucune ligne n’a été perdue. Je teste le tunnel de commande complet sur chaque moyen de paiement actif, les pages clés du front (accueil, catégorie, fiche produit) et l’accès au back-office. Je consulte aussi le journal d’erreurs PHP dans les premières heures : c’est souvent là qu’apparaissent les surcharges auxquelles il manque un type de retour.
Pages liées
-
Checklist avant une migration
Ce qu’il faut vérifier et sauvegarder avant une migration, quelle que soit la version de départ.
-
Modules incompatibles après migration
Pourquoi un module qui fonctionnait plante ou disparaît après une mise à jour, et comment vérifier sa compatibilité.
-
Passer PrestaShop à PHP 8
Ce qu’implique le changement de version PHP côté hébergement, indépendamment de la version de PrestaShop.
-
Migration PrestaShop 8 vers 9
L’étape suivante logique une fois la boutique stabilisée sur la version 8.
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.