Dans quel ordre mettre à jour PrestaShop, PHP, le thème et les modules sans casser la boutique

Une boutique PrestaShop compte quatre éléments qui vieillissent à des rythmes différents : le cœur, la version de PHP du serveur, le thème et les modules. Chacun a ses propres versions et chacun exige quelque chose des autres. Si vous les mettez à jour dans n'importe quel ordre, vous finirez tôt ou tard par tomber sur une combinaison qui ne fonctionne pas : un module qui ne démarre pas avec le nouveau PHP, un thème qui appelle une fonction que le cœur n'a plus ou un cœur qui ne s'installe pas parce que PHP est trop ancien.

La bonne nouvelle, c'est que le bon ordre se déduit presque toujours d'une seule règle. La voici, avec la procédure complète.

La règle : ne jamais passer par une combinaison non prise en charge

Chaque version de PrestaShop accepte une plage de versions de PHP. Chaque module et chaque thème indiquent (ou devraient indiquer) avec quelles versions de PrestaShop et de PHP ils fonctionnent. Bien mettre à jour consiste à avancer par étapes de sorte que, après chaque étape, tous les éléments restent dans ce qu'ils prennent en charge.

Cela a une conséquence pratique : vous ne pouvez presque jamais sauter directement à la fin. Si votre boutique est sur une ancienne version avec un ancien PHP, et que la version cible exige un PHP plus récent que la version d'origine ne supporte pas, il vous faut une étape intermédiaire. Parfois c'est une version intermédiaire du cœur ; parfois, une version intermédiaire de PHP acceptée par les deux.

Avant de toucher à quoi que ce soit : l'inventaire

Dressez un tableau de tout ce que contient la boutique. Sans lui, l'ordre relève de la devinette.

• Version exacte du cœur et version de PHP utilisée par le site (qui peut différer de celle du terminal du serveur).
• Thème : s'il s'agit du thème par défaut, d'un thème acheté ou d'un thème sur mesure, s'il a un thème enfant et qui le maintient.
• Modules installés, avec version, auteur et provenance du téléchargement. Repérez ceux que vous n'utilisez plus : il ne faut pas les mettre à jour, il faut les retirer.
• Overrides dans le dossier override/. Ce sont les premiers à casser quand le cœur change, car ils remplacent des classes entières ou des méthodes dont la signature a pu changer.
• Intégrations externes : ERP, passerelles de paiement, marketplaces, transporteurs. Chacune est un module ou un script qui dépend lui aussi des versions.

Pour chaque module, notez la dernière version compatible avec votre cœur actuel et avec le cœur cible. Ceux qui n'ont pas de version pour la cible représentent le vrai travail du projet : il faut trouver un remplaçant, la demander à l'auteur ou les adapter.

L'ordre qui fonctionne dans la plupart des cas

1. Sauvegarde complète des fichiers et de la base de données, et vérification qu'elle peut être restaurée.
2. Retirez ce qui est superflu. Modules désinstallés qui restent sur le disque, modules installés que personne n'utilise, overrides orphelins. Chaque élément retiré est un élément de moins à mettre à jour et à tester.
3. Mettez à jour les modules dans votre version actuelle jusqu'à la dernière version qui la prend en charge. Bien souvent, cette même version fonctionne déjà sur le cœur cible, et le grand saut se fait ainsi avec des modules récents.
4. Mettez à jour le thème vers la dernière version compatible avec votre cœur actuel, si l'éditeur en propose une. S'il s'agit d'un thème sur mesure, examinez d'abord les templates qui changent le plus d'une version à l'autre : checkout, panier et fiche produit.
5. Mettez à jour le cœur, d'abord vers la dernière révision de votre branche puis, si nécessaire, vers la branche suivante.
6. Changez la version de PHP pour la plus récente prise en charge par le nouveau cœur et acceptée par tous vos modules.
7. Revérifiez modules et thème : certains ont une version spécifique à la nouvelle branche qui ne peut être installée qu'une fois le cœur mis à jour.

Pourquoi sur une copie et pas en production

Tout ce qui précède se répète d'abord sur une copie de la boutique, avec les mêmes fichiers, la même base de données et, si possible, le même PHP et la même configuration serveur. Sur la copie, vous pouvez vous tromper, revenir en arrière et recommencer. En production, chaque tentative ratée est vue par vos clients.

Pendant la répétition, notez chaque étape avec assez de détails pour la refaire : quel module a été mis à jour, dans quel ordre, quel réglage a dû être modifié à la main, quel fichier du thème a été corrigé. Le jour du changement, on n'improvise pas : on suit la liste.

Quoi tester après chaque étape

• Page d'accueil, une catégorie avec filtres, une fiche avec déclinaisons et le moteur de recherche.
• Création de compte client, connexion et récupération du mot de passe.
• Une commande complète avec chaque moyen de paiement, dans le mode test de chaque passerelle, jusqu'à voir la commande dans le bon état.
• Les e-mails envoyés au client (sans qu'ils n'arrivent à une vraie personne : sur la copie, le courrier doit être capturé).
• Back-office : liste des commandes, fiche d'une commande, facture PDF, modification d'un produit.
• Le journal d'erreurs PHP et celui de PrestaShop : ce qui ne casse pas la page compte aussi.

Ce qui casse le plus souvent

• Les overrides qui redéfinissent des méthodes du cœur qui ont changé. Le symptôme est une erreur fatale juste après la mise à jour, parfois sur une seule page.
• Les modules de paiement dans d'anciennes versions qui utilisent des hooks ou des classes retirés. Ce sont les plus délicats, car la panne peut se situer au retour de la passerelle : le client paie et la commande n'est pas créée.
• Les templates du thème qui attendent des variables que le cœur n'envoie plus ou qui portent un autre nom.
• Les fonctions PHP supprimées ou les comportements qui passent d'avertissement à erreur lors d'une montée de version. Un module qui fonctionnait avec des avertissements masqués peut cesser complètement de fonctionner.
• Les caches qui conservent des classes compilées de la version précédente. Les vider fait partie de la procédure, ce n'est pas une astuce de dernière minute.

La fenêtre du changement

Une fois la répétition faite, choisissez quand l'appliquer en production :

• Un moment de faible trafic que vous pouvez constater dans vos statistiques, pas celui que tout le monde suppose.
• Loin des campagnes et des grosses journées d'expédition. Ne mettez pas à jour la veille des soldes ni un vendredi après-midi si personne n'est là pour surveiller le lundi.
• Avec les personnes disponibles : celle qui fait le changement, celle qui teste les paiements et celle qui peut appeler l'hébergeur si nécessaire.
• Avec un plan de retour arrière écrit : quelle sauvegarde est restaurée, combien de temps cela prend et à partir de quel symptôme on décide de revenir en arrière. Si la boutique a reçu des commandes entre la sauvegarde et le retour arrière, il faut savoir comment les récupérer.

Passez la boutique en maintenance pendant le changement, en laissant l'accès à votre IP pour tester, et ne la rouvrez qu'après avoir effectué la même liste de tests que lors de la répétition.

Après le changement

Les premiers jours sont consacrés à la surveillance. Consultez le journal d'erreurs, comparez les commandes avec les encaissements de la passerelle et demandez au service client s'il reçoit des demandes inhabituelles. Beaucoup de pannes liées à une mise à jour n'apparaissent pas dans la première heure, mais lorsque quelqu'un utilise pour la première fois une fonction peu courante : un bon de réduction particulier, un transporteur qui ne s'affiche que pour certaines provinces ou une facture rectificative.

Et consignez l'état final dans l'inventaire. La prochaine mise à jour commence là, et elle sera beaucoup plus courte si vous ne laissez pas passer des années entre deux mises à jour.

Comment le résoudre dans PrestaShop

Chez Rekire, nous faisons ce travail tous les jours, de la mise à jour de révision au sein d'une même branche à la migration entre versions majeures. Avec un forfait d'heures de support (20 ou 50 heures, selon la taille de la boutique), nous préparons l'inventaire du cœur, de PHP, du thème et des modules, nous montons la copie de test, nous répétons l'ordre de mise à jour avec sa liste de tests et nous appliquons le changement en production dans la fenêtre que vous choisissez. Les heures sont décomptées selon le travail réel : vous pouvez commencer par l'inventaire et décider ensuite jusqu'où aller.