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

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Migrer une boutique PrestaShop 1.7 vers la version 9

Sauter directement de 1.7 à 9, c’est franchir en une fois le passage à Symfony 6.4, à PHP 8.1 minimum et à un back-office entièrement Twig : un saut plus lourd qu’il n’y paraît.

Décrire mon problème Discuter sur WhatsApp

Ce qui change entre 1.7 et 9

Entre PrestaShop 1.7 et 9, l’écart n’est plus une question de version : c’est un changement de génération. La 1.7 repose sur une architecture hybride, une partie du back-office et certains contrôleurs front en Symfony, le reste en Smarty pur avec des contrôleurs d’administration legacy. PrestaShop 9 supprime ces derniers : le back-office repose désormais entièrement sur des contrôleurs Symfony et Twig, et Symfony lui-même passe à la 6.4 LTS, contre une base bien plus ancienne côté 1.7/8. Côté PHP, 1.7 plafonne à 7.4 sur sa dernière sous-version, alors que 9 demande PHP 8.1 minimum et prend en charge 8.2, 8.3 et 8.4 : aucun recouvrement direct entre les deux plages.

PrestaShop 9 ajoute aussi une nouvelle API d’administration, l’Admin API, basée sur API Platform avec authentification OAuth. Côté thème, la 9 introduit Hummingbird, mais Classic reste le défaut à la sortie : pas de reconstruction de thème obligatoire, contrairement au passage 1.6 vers 1.7.

La base de données change de structure à chaque version majeure ; ici, deux paliers (1.7 vers 8, puis 8 vers 9) doivent être couverts par les scripts d’autoupgrade, en une opération ou en deux.

Ce qui casse sur un tel écart de version

  • Un module qui s’appuie sur un contrôleur legacy en Smarty ne trouve plus ce contrôleur en 9 : il ne plante pas, il disparaît.
  • Une surcharge de méthode du cœur écrite pour 1.7 ignore les types de retour exigés depuis PHP 8.1 : erreur fatale, pas un avertissement.
  • Un module utilisant encore la syntaxe accolades pour un tableau ou une chaîne ($array{0}) ne s’exécute plus sous PHP 8.1 ou supérieur.
  • Une intégration développée sur l’ancienne API web service n’a pas été pensée pour l’authentification OAuth de la nouvelle Admin API et doit être revue.
  • Un module dont la compatibilité déclarée dans config.xml s’arrête à la version 8 est refusé à l’installation sur une 9.

Comment j’aborde ce saut de version

  1. Audit et décision du parcours

    Je liste modules, surcharges de contrôleurs et de templates back-office, et intégrations utilisant l’API web service actuelle, puis je décide du découpage. autoupgrade enchaîne les paliers sans en sauter aucun : les scripts de mise à jour de chaque version intermédiaire s’exécutent de toute façon, la question est seulement de savoir si je les laisse défiler dans un seul lancement ou si je marque un arrêt en 8 pour vérifier l’état de la boutique, notamment quand des modules ou surcharges legacy sont encore en usage.

  2. Sauvegarde complète indépendante

    Dump SQL complet et copie intégrale des fichiers avant toute opération, en plus de la sauvegarde interne d’autoupgrade, conservés hors du serveur modifié.

  3. Migration sur copie de la boutique

    Toute la procédure est rejouée sur un environnement de test, PHP cible déjà en place, pour voir apparaître erreurs de type de retour et contrôleurs manquants avant qu’ils ne touchent le site réel.

  4. Le point de non-retour : l’exécution des scripts de base

    Dès que les scripts de mise à jour s’exécutent, seule la restauration du dump pris avant l’opération permet un retour en arrière propre. Cette étape n’est lancée qu’après validation complète sur l’environnement de test.

  5. Réécriture des contrôleurs et modules legacy

    Les contrôleurs d’administration encore en Smarty et les modules qui en dépendent sont réécrits pour l’architecture Symfony/Twig de la 9, pas mis à jour.

  6. Bascule en production

    Une fois la version de test validée et le PHP cible confirmé, je programme la bascule à faible trafic.

Comment je vérifie après coup

Je compare les volumes de commandes, clients et produits entre ancienne et nouvelle base après chaque palier. Je teste le tunnel de commande sur chaque moyen de paiement, que les contrôleurs réécrits fonctionnent pour chaque profil back-office, et qu’aucune intégration API n’est restée sur l’ancienne authentification. Je surveille aussi le journal d’erreurs PHP les premiers jours, en particulier les erreurs de type de retour qui n’apparaissent parfois qu’à l’usage réel d’une fonctionnalité peu utilisée.

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

Faut-il obligatoirement passer par la version 8 avant la 9 ?
Pas d’un arrêt obligatoire, non : autoupgrade enchaîne les paliers sans en sauter aucun, les scripts de la 8 s’exécutent même si vous visez directement la 9. Mais plus l’écart est grand, plus de scripts s’exécutent dans le même lancement, et plus la fenêtre à risque s’allonge. Je décide au cas par cas si marquer un arrêt en 8 réduit le risque.
Mes contrôleurs d’administration personnalisés en Smarty vont-ils continuer à fonctionner en 9 ?
Non, pas tels quels. PrestaShop 9 supprime les derniers contrôleurs legacy : tout contrôleur back-office en Smarty doit être réécrit pour l’architecture Symfony/Twig de la 9, il ne se met pas à jour automatiquement.
Combien de temps prend un tel saut de version ?
Nettement plus qu’un passage de 1.7 vers 8 : audit, réécriture éventuelle de contrôleurs legacy et tests sur copie se comptent en semaines plutôt qu’en jours dès qu’il y a des personnalisations d’administration.
Mon référencement va-t-il être affecté ?
Pas par le changement de version lui-même, si URLs et structure des pages sont conservées. Je surveille les redirections pendant l’opération, surtout en deux paliers.

Pages liées