Mon site a cassé après une mise à jour
Une mise à jour qui casse quelque chose n’a presque jamais changé une seule chose. Elle a modifié le cœur, parfois la base de données, souvent des fichiers que d’autres composants utilisaient, et elle a laissé en place des éléments qui n’ont pas suivi. Comprendre ce qui a réellement bougé décide de la suite : corriger, ou revenir en arrière.
Ce qu’une mise à jour modifie réellement
Trois choses changent en même temps. Le code du cœur est remplacé : les fonctions supprimées ou renommées ne sont plus disponibles pour les modules qui les appelaient. La structure de la base peut évoluer : nouvelles colonnes, nouvelles tables, données converties. Et le cache compilé devient obsolète : il référence des fichiers qui n’existent plus sous la même forme.
Ce qui ne change pas, ce sont les personnalisations : surcharges, modifications faites directement dans les fichiers du cœur, thème adapté. Elles restent écrites pour l’ancienne version. C’est là que se produit la casse dans la majorité des cas, et c’est aussi pourquoi une mise à jour qui se passe bien chez un marchand se passe mal chez un autre avec exactement la même version.
Cadrer avant de décider
-
Décrire précisément ce qui ne marche plus
Une fonction, une page, un rôle d’utilisateur, ou tout le site ? Un défaut limité se corrige ; un site entier hors service justifie un retour en arrière immédiat.
-
Vérifier si la base a été modifiée
C’est le point décisif. Si la mise à jour a converti des données, une restauration des seuls fichiers ne suffira pas, et une restauration complète fera perdre les commandes prises depuis.
-
Vider les caches avant de conclure
Une part notable des symptômes qui suivent une mise à jour vient d’un cache compilé resté en place. C’est la vérification la moins coûteuse de la liste.
-
Lister les composants non mis à jour
Modules, extensions, thème : ceux qui sont restés à leur version précédente sont les premiers suspects. La date de dernière mise à jour de chacun est un indice fiable.
-
Regarder le journal d’erreurs de la période
Il nomme le fichier et la fonction en cause. C’est ce qui distingue une correction ciblée d’une désactivation à l’aveugle.
Corriger plutôt que reculer
Dans la plupart des situations que je traite, la correction ciblée est préférable au retour en arrière. Un module incompatible peut être remplacé, mis à jour, ou son appel adapté. Une surcharge écrite pour l’ancienne version peut être réécrite. Un thème qui utilise une fonction disparue peut être ajusté sur les quelques fichiers concernés.
- Le retour en arrière garde son sens quand la mise à jour vient d’être lancée et qu’aucune donnée nouvelle n’a été enregistrée.
- Il perd son sens dès que la boutique a repris son activité.
- Dans tous les cas, la copie de l’état actuel se fait avant toute manipulation, y compris avant une restauration.
Continuer sur la bonne page
-
Préparer une mise à jour majeure
Ce qu’il faut vérifier avant, pour que la situation ne se répète pas.
-
Restaurer après une mise à jour ratée
La marche à suivre quand le retour en arrière est réellement la bonne option.
-
Conflit d’extensions après mise à jour
La méthode d’isolement quand deux composants se disputent la même fonction.
-
Moyen de paiement disparu après une mise à jour
Le cas le plus coûteux, quand c’est le paiement qui a cessé de s’afficher.
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.