Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

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.

Décrire mon problème Discuter sur WhatsApp

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

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.

Quelle est la version actuelle ?
Vers quelle version souhaitez-vous aller ?
Quelle est la taille du catalogue ?

C’est le premier facteur de durée d’une migration, avant même le nombre de modules.

La boutique utilise-t-elle beaucoup de modules tiers ou personnalisés ? (facultatif)

Chaque module non natif doit être vérifié, remplacé ou réécrit pour la version cible.

Qu’est-ce qui doit impérativement être conservé ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Dois-je être sur la dernière sous-version 1.7.8 avant de passer à la 8 ?
Pas une obligation stricte, mais la configuration la plus testée pour autoupgrade : je vérifie l’état de votre 1.7 avant la mise à jour, et je monte la boutique jusqu’à la dernière sous-version 1.7 si nécessaire.
Le TypeScript du nouveau back-office va-t-il casser mes personnalisations d’administration ?
Seulement si vous avez des scripts ou surcharges JavaScript spécifiques dans le back-office. Le fonctionnement standard de l’administration n’est pas affecté ; c’est le code personnalisé qui doit être adapté.
Combien de temps dure une migration de 1.7 vers 8 ?
Ça dépend surtout du nombre de modules et de surcharges personnalisées. Une boutique avec peu de modules et un thème standard se migre en quelques jours ; une personnalisation poussée prend plus de temps.
Mon hébergement doit-il changer avant la migration ?
En général oui. Je vérifie la version PHP proposée par l’hébergeur au regard de PrestaShop 8 ; si elle manque, je signale ce changement avant la mise à jour de PrestaShop.