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

Mettre à jour un thème et ses extensions avant une montée de version

Avant de monter de version, l’ordre dans lequel je mets à jour compte autant que la mise à jour elle-même. Extensions d’abord, thème ensuite, cœur WordPress en dernier : inverser cet ordre expose une période intermédiaire où thème et extensions tournent sur une version de WordPress qu’ils n’ont jamais rencontrée.

Décrire mon problème Discuter sur WhatsApp

Pourquoi l’ordre change tout

Une extension ou un thème n’est jamais testé par son auteur contre une version de WordPress qui n’existe pas encore. Quand je mets à jour le cœur WordPress en premier, je place immédiatement le site dans une configuration que personne n’a validée : le thème et les extensions actifs tournent alors sur une version plus récente que celle contre laquelle ils ont été développés et testés.

À l’inverse, les auteurs d’extensions publient en général leurs mises à jour de compatibilité avant la sortie officielle d’une nouvelle version majeure de WordPress, parce qu’ils suivent les versions bêta et les notes de développement. Le thème suit souvent avec un peu de retard, surtout s’il dépend lui-même d’extensions tierces (constructeur de pages, framework de thème). Le cœur WordPress, lui, reste le composant le plus stable et le mieux couvert par la rétrocompatibilité : c’est la dernière brique à faire évoluer, une fois que tout ce qui en dépend a déjà prouvé qu’il fonctionne avec la nouvelle version.

Le risque spécifique d’un thème modifié directement, sans thème enfant, mérite d’être signalé à part : toute mise à jour de ce thème écrase les fichiers modifiés, qu’elle intervienne avant ou après le cœur. Si le site est dans ce cas, la première étape n’est pas de mettre à jour le thème mais de migrer les personnalisations vers un thème enfant, sans quoi chaque mise à jour du thème efface le travail déjà fait.

Conséquences typiques d’un cœur mis à jour en premier

  • Fonctions de thème qui appellent une fonction du cœur dépréciée dans la nouvelle version, avant que le thème n’ait été adapté
  • Extensions qui affichent une erreur fatale au chargement parce qu’elles ciblent une version de WordPress antérieure
  • Éditeur de blocs qui se comporte différemment sur des mises en page construites avec l’ancienne version du thème
  • Personnalisations ajoutées directement dans les fichiers du thème, écrasées à la première mise à jour du thème
  • Période d’instabilité prolongée pendant laquelle chaque composant est mis à jour dans l’urgence, un par un, en réaction aux pannes

L’ordre que je suis, étape par étape

  1. Vérifier la présence d’un thème enfant

    Si le thème actif est modifié directement, je migre d’abord les personnalisations vers un thème enfant. Sans cette étape, toute mise à jour du thème parent efface le travail fait dessus.

  2. Mettre à jour les extensions, une par une

    Je commence par les extensions, en vérifiant après chacune que le site fonctionne toujours, plutôt qu’en les mettant toutes à jour en bloc sans contrôle intermédiaire.

  3. Mettre à jour le thème (ou le thème parent seulement)

    Une fois les extensions stables, je mets à jour le thème. Si un thème enfant est en place, seul le parent est remplacé ; les personnalisations dans le thème enfant restent intactes.

  4. Vérifier le site avant de toucher au cœur

    Je parcours les pages clés et le tunnel de commande avec les extensions et le thème à jour, mais le cœur encore sur l’ancienne version, pour isoler l’origine de tout problème restant.

  5. Mettre à jour le cœur WordPress en dernier

    C’est le point de non-retour : une fois le cœur mis à jour, revenir en arrière demande une restauration complète plutôt qu’une simple annulation, alors que revenir sur une seule extension ou un thème reste rapide.

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.

D’où partez-vous ?
Quelle est la taille du catalogue, s’il y a une boutique ?
Le site utilise-t-il des extensions payantes avec licence à retransférer ? (facultatif)

Certaines licences sont limitées à un domaine ou nécessitent une réactivation auprès de l’éditeur.

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 ne pas mettre à jour le cœur WordPress en premier, puisque c’est la base de tout ?
Parce que thème et extensions n’ont alors pas encore été confrontés à cette nouvelle version. La période intermédiaire tourne sur une combinaison que personne n’a testée, ce qui est justement ce qu’on cherche à éviter.
Faut-il mettre à jour toutes les extensions en une seule fois ?
Non, je préfère les mettre à jour une par une avec une vérification entre chaque, pour identifier immédiatement laquelle pose problème plutôt que de devoir tester dix changements à la fois après coup.
Mon thème est modifié directement, dois-je le mettre à jour quand même ?
Non, pas dans cet état. La première étape est de créer un thème enfant et d’y déplacer les personnalisations. Mettre à jour un thème modifié directement efface ce travail, quel que soit le moment choisi.
Que faire si une extension n’a pas encore de version compatible avec le cœur à venir ?
Je retarde la mise à jour du cœur jusqu’à ce qu’une version compatible sorte, ou je cherche une extension équivalente si celle en place n’est plus maintenue activement.
Combien de temps se passe entre chaque étape ?
Je vérifie le fonctionnement du site après chaque étape avant de passer à la suivante, ce qui prend en général une à deux journées au total pour une boutique avec plusieurs extensions actives.

Pages liées