Migrer une boutique PrestaShop 1.6 vers 1.7
Passer de PrestaShop 1.6 à 1.7 est le premier palier obligatoire pour aller plus loin : le moteur de thème change, une partie du back-office bascule sur Symfony, et le hook des moyens de paiement au tunnel de commande n’est plus le même. Voici ce qui casse concrètement et comment je procède.
Ce qui change réellement entre 1.6 et 1.7
PrestaShop 1.6 tourne sur un framework « legacy » propriétaire et un templating 100 % Smarty, avec le thème par défaut Default. À partir de la 1.7, une partie de l’admin et certains contrôleurs du front basculent sur Symfony avec Twig, le reste restant en Smarty : l’architecture devient hybride. Le thème par défaut change aussi de nom, Classic remplace Default, sur base Bootstrap 4 alors que le thème 1.6 était en Bootstrap 3. Un thème 1.6, même personnalisé, ne s’installe donc pas tel quel sur 1.7 : il doit être reconstruit template par template.
Le changement qui casse le plus souvent les boutiques concerne le tunnel de commande. En 1.6, les modules de paiement s’accrochent au hook displayPayment. À partir de la 1.7, ce hook est remplacé par paymentOptions. Un module non mis à jour disparaît purement et simplement de l’étape de paiement, sans erreur visible : le client ne peut plus payer.
La structure de la base évolue aussi entre les deux versions majeures, avec de nouvelles tables et des colonnes renommées : un dump SQL brut restauré tel quel n’est pas fiable, c’est le module officiel autoupgrade qui exécute les scripts de mise à jour de schéma nécessaires.
Ce qui casse typiquement lors d’une migration 1.6 vers 1.7
- Le module de paiement disparaît du tunnel de commande sans erreur visible : le hook displayPayment n’est plus appelé.
- Le thème affiche une page blanche ou un rendu cassé : les templates .tpl de la 1.6 ne correspondent plus à l’arborescence de la 1.7.
- Certains écrans du back-office changent d’emplacement, une partie de l’admin étant désormais gérée par des contrôleurs Symfony.
- Les modules utilisant l’ancienne syntaxe $array{0} entre accolades provoquent des erreurs fatales si PHP a aussi été mis à jour.
Comment je conduis une migration 1.6 vers 1.7
-
Inventaire des modules et du thème
Je liste chaque module installé, sa version, et vérifie s’il déclare une compatibilité 1.7 dans son fichier de configuration — même chose pour le thème.
-
Sauvegarde complète avant toute manipulation
Je sauvegarde l’intégralité des fichiers, un dump complet de la base, et la configuration des modules critiques (paiement, transporteurs) avant de lancer quoi que ce soit.
-
Migration sur une copie de la boutique
Je lance autoupgrade sur un environnement de test, jamais en production. Il sauvegarde à son tour fichiers et base avant la mise à jour, avec restauration possible en cas d’erreur.
-
Reconstruction du thème et remplacement du hook de paiement
J’adapte ou reconstruis le thème sur la base de Classic, et je vérifie que chaque module de paiement utilise paymentOptions plutôt que l’ancien displayPayment.
-
Vérification puis bascule
Une fois la boutique de test validée, je programme la bascule en production à faible trafic, pour limiter l’impact sur les commandes en cours.
Sauvegardes et vérifications après la migration
Avant de lancer quoi que ce soit, je sauvegarde l’arborescence complète (fichiers .php, thème, modules, images), un dump de la base, et la configuration des modules de paiement et transport, les plus sensibles à une bascule de hook — conservée en dehors du dossier autoupgrade/backup, qui peut être écrasé par une tentative suivante.
Après la migration, je vérifie que le nombre de commandes, clients et produits correspond exactement à l’avant, que les URLs principales répondent avec le bon code, et que les redirections fonctionnent. Je teste aussi un passage de commande complet, du panier au paiement, pour confirmer que le module de paiement apparaît bien via paymentOptions.
// PS 1.6
$this->registerHook('displayPayment');
// PS 1.7+
$this->registerHook('paymentOptions');Pour préparer ou compléter cette migration
-
Checklist avant migration
Ce que je vérifie avant toute migration PrestaShop, quelle que soit la version.
-
Modules incompatibles
Comment je repère les modules qui ne passeront pas et par quoi je les remplace.
-
Conserver son référencement
Ce qu’il faut vérifier sur URLs et redirections pour ne pas perdre le référencement acquis.
-
Migrer sans interruption de vente
La méthode pour basculer en production sans bloquer les commandes en cours.
- PHP 5.2 à 7.1 PrestaShop 1.6
- PHP 7.2 à 7.4 selon la sous-version PrestaShop 1.7
devdocs.prestashop-project.org
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.