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 de PrestaShop 8.0 vers PrestaShop 8.2

Passer de PrestaShop 8.0 à 8.2 ressemble à une mise à jour mineure : même branche majeure, même thème, même structure de base. C’est trompeur. Entre les deux se trouve la 8.1, qui fait passer le back-office de Vue.js 2.6 à 3.2 — et c’est précisément ce qui casse les personnalisations JavaScript de l’administration.

Décrire mon problème Discuter sur WhatsApp

Ce qui change réellement entre 8.0 et 8.2

PrestaShop 8.0 exige au minimum PHP 7.2.5 et ajoute la prise en charge de PHP 8.0 et 8.1. Le JavaScript des pages déjà migrées y est écrit en TypeScript, et de nombreuses méthodes déclarent un type de retour, du fait de la compatibilité PHP 8.1.

Entre les deux se trouve la version 8.1, sortie en juin 2023 : c’est elle qui fait passer Vue.js de 2.6 à 3.2 dans le back-office, ajoute la compatibilité multi-boutique sur la page client, et introduit de nouvelles fonctionnalités de sécurité. PrestaShop 8.2, sorti en septembre 2024, apporte ensuite la prise en charge complète de PHP 8.2, avec des correctifs de performance et de sécurité. La branche 8.2.x est ensuite la seule de la série 8 à recevoir encore des correctifs de bugs critiques et de failles de sécurité ; l’éditeur n’a pas publié de date de fin pour ce suivi.

Sur le papier, 8.0 vers 8.2 reste dans la même branche majeure : la numérotation suggère une mise à jour mineure. En réalité, ce trajet traverse un changement de version majeure de Vue.js, un framework dont l’API interne n’est pas compatible d’une version majeure à l’autre pour tout ce qui manipule directement ses composants.

Pourquoi une mise à jour « mineure » casse le back-office

Vue 2 et Vue 3 ne partagent pas la même API interne pour définir et manipuler les composants. Un widget d’administration sur mesure, ou un module qui ajoute un onglet à l’interface en s’appuyant directement sur des composants Vue 2, cesse de fonctionner une fois le back-office passé sur Vue 3 : ce n’est pas une question de configuration, le code qui manipulait Vue 2 n’a simplement plus d’équivalent direct.

C’est ce qui distingue ce couple de versions d’une simple mise à jour de sécurité : le numéro suggère un changement mineur, mais le passage par la 8.1 embarque une rupture technique réelle pour tout développement touchant l’interface d’administration.

Côté catalogue, commandes et front-office public, l’impact est généralement faible. La structure de la base ne change pas entre 8.0 et 8.2, et le thème public n’est pas concerné par ce changement de framework JavaScript. Le risque se concentre sur le JavaScript de l’administration et les modules qui y touchent directement.

Signes qu’une personnalisation va casser en passant par la 8.1 puis la 8.2

  • Un module ajoute un onglet ou un widget personnalisé en manipulant directement des composants Vue.js.
  • Un développement sur mesure appelle l’API interne de Vue 2 (options API, mixins) plutôt qu’un point d’extension officiel PrestaShop.
  • Le module n’a pas été mis à jour depuis avant juin 2023, date de sortie de la 8.1.
  • La documentation du module ne précise aucune compatibilité au-delà de la 8.0.

Comment je conduis cette migration mineure

  1. Audit des personnalisations du back-office

    Je repère les modules et développements sur mesure touchant l’interface d’administration : onglets, widgets, composants JavaScript.

  2. Sauvegarde des fichiers et de la base

    Sauvegarde complète avant toute opération, en plus de celle que le module autoupgrade réalise dans <dossier-admin>/autoupgrade/backup.

  3. Migration sur copie de la boutique

    Je fais transiter la copie par la 8.1 puis la 8.2 avec autoupgrade, pour isoler à quelle étape une personnalisation cesse de fonctionner.

  4. Exécution de la mise à jour

    Point de non-retour : une fois la mise à jour validée par autoupgrade, revenir en arrière suppose de restaurer la sauvegarde complète plutôt que d’annuler l’étape.

  5. Correction du JavaScript admin cassé

    Je réécris les personnalisations qui manipulaient Vue 2 pour les adapter à Vue 3, ou je les remplace par un point d’extension officiel quand c’est possible.

  6. Vérification et bascule

    Je contrôle en priorité le back-office (onglets, widgets, formulaires), puis le catalogue et les commandes, avant de basculer la production.

Pour aller plus loin

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

Pourquoi une mise à jour mineure comme 8.0 vers 8.2 casserait-elle quelque chose ?
Parce qu’entre les deux se trouve la 8.1, qui fait passer le back-office de Vue.js 2.6 à 3.2. Le numéro reste dans la même branche majeure, mais ce changement de framework casse réellement les personnalisations manipulant directement des composants Vue 2.
Dois-je m’inquiéter pour mon catalogue ou mes commandes ?
En règle générale non : la structure de la base ne change pas entre 8.0 et 8.2, et le thème public n’est pas concerné. Le risque se concentre sur l’administration.
Puis-je passer directement de 8.0 à 8.2 sans passer par la 8.1 ?
Autoupgrade gère l’enchaînement des mises à jour successives. Je teste néanmoins sur une copie pour vérifier qu’aucune personnalisation ne casse au passage par la 8.1.
Pourquoi migrer vers 8.2 si c’est risqué pour l’administration ?
Parce que la 8.2.x est la seule branche de la série 8 qui reçoit encore des correctifs de bugs critiques et de failles de sécurité. Rester sur 8.0 expose à des failles non corrigées, un risque généralement plus grand que corriger quelques personnalisations.

Pages liées