Un module cassé par sa propre mise à jour
Le module fonctionnait, vous avez accepté la mise à jour proposée, et depuis il ne fonctionne plus. Ce n’est pas de la malchance : un changement de version majeure d’un module réécrit souvent sa configuration et ses tables, et ce passage est le moment le plus fragile de sa vie.
Ce qu’une mise à jour de module fait réellement
Mettre à jour un module ne se limite pas à remplacer des fichiers. Sur PrestaShop comme sur WordPress, un module bien écrit exécute au passage une procédure de mise à niveau : elle peut ajouter des colonnes en base, renommer des clés de configuration, migrer d’anciens réglages vers un nouveau format, ou se raccrocher à d’autres points d’affichage.
Trois choses peuvent mal se passer. La procédure s’interrompt à mi-parcours, et la base se retrouve dans un état intermédiaire que le module ne sait pas relire. Les anciens réglages ne sont pas repris, et le module redémarre avec ses valeurs par défaut, ce qui donne l’impression qu’il ne fait plus rien. Ou la nouvelle version exige une version de PHP ou de la plateforme supérieure à la vôtre, et échoue silencieusement au chargement.
Le cas le plus déroutant est celui où le module semble fonctionner, mais où une partie seulement de ses réglages a survécu. Vous cherchez un bug là où il n’y a qu’une configuration perdue.
Quoi faire, et dans quel ordre
-
Ne pas relancer la mise à jour en boucle
Relancer une procédure de mise à niveau qui a échoué à mi-chemin peut aggraver l’état de la base, parce qu’elle rejoue des opérations déjà effectuées. Un état intermédiaire se répare, un état rejoué trois fois se répare beaucoup moins bien.
-
Lire le journal d’erreurs du serveur
Une exigence de version non satisfaite, une méthode manquante ou une colonne inexistante y apparaissent nommément. C’est ce qui distingue une incompatibilité d’un réglage perdu.
-
Comparer la configuration avant et après
Si vous disposez d’une sauvegarde antérieure, les valeurs de configuration du module s’y retrouvent et se comparent. C’est souvent là que se trouve l’explication complète.
-
Revenir à la version précédente, si c’est possible
Redescendre de version n’est sûr que si la base n’a pas été modifiée par la mise à niveau. Sinon, restaurer une sauvegarde complète du site est la seule marche arrière fiable.
Le cas particulier des modules de paiement et de transport
Ces modules-là méritent une attention distincte, parce que leur panne ne se voit pas sur la page d’accueil mais à la dernière étape du tunnel, c’est-à-dire au moment où vous perdez la vente. Une nouvelle version majeure change fréquemment la façon dont le module reçoit les retours du prestataire, et ces retours arrivent sur une adresse enregistrée chez le prestataire, pas dans votre boutique. Si la mise à jour change cette adresse, il faut la mettre à jour des deux côtés.
Après toute mise à jour d’un module de paiement, je passe une commande réelle de bout en bout, en conditions de production, et je vérifie que la commande est bien créée avec le bon statut. C’est le seul test qui prouve quelque chose.
Pages liées
-
Tester un module avant la production
La façon d’éviter complètement ce problème : mettre à jour d’abord sur une copie.
-
Sauvegarder la boutique avant intervention
La sauvegarde qui rend le retour en arrière possible, fichiers et base ensemble.
-
Un moyen de paiement disparaît après une mise à jour
Le cas précis d’un module de paiement qui ne s’affiche plus au tunnel.
-
Restaurer après une mise à jour ratée
La procédure de remise en état côté WordPress et WooCommerce.
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.