Fonction WordPress cassée après deux mises à jour : isoler le conflit

Définir ce qui a cessé de fonctionner

Après la mise à jour de deux extensions, un formulaire ne réagit plus, un bloc n’apparaît plus ou un écran renvoie une erreur. Les deux changements sont proches de l’incident, mais cette chronologie ne désigne pas automatiquement le responsable. Le résultat recherché est une comparaison reproductible, puis une correction qui rétablit la fonction sans supprimer ses données.

Notez l’action précise, l’adresse ou l’écran, le résultat attendu et le résultat observé. Distinguez la consultation d’un formulaire de son envoi réel, l’ouverture d’une commande de son remboursement et l’affichage d’une page de son enregistrement. Un essai de dépannage ne doit pas répéter une opération métier dont le résultat reste incertain.

Ce guide suppose que l’administration reste accessible et que le problème concerne une fonction identifiée. Une erreur critique qui bloque tout le site demande d’abord le parcours de récupération correspondant. Sur un réseau multisite, faites vérifier les activations au niveau du réseau ; désactiver un composant peut concerner plusieurs sites et leurs dépendances.

Relever les versions et l’état avant de modifier encore le site

Dans Extensions installées, relevez le nom exact, la version et l’état des deux composants mis à jour. Appelez-les A et B dans vos notes pour garder une comparaison lisible, mais conservez leurs vrais noms dans le dossier d’intervention. Si vous connaissez les versions précédentes et l’heure des mises à jour, ajoutez-les.

Dans Outils, Santé du site, Informations, relevez WordPress, PHP et le thème actif. Notez aussi les autres changements survenus au même moment : réglage de cache, déploiement du thème ou modification d’un modèle. Une copie de test qui possède un autre PHP ou une autre configuration ne fournit pas exactement la même comparaison.

Conservez une capture du message ou du comportement, sans données personnelles ni secrets. Pour un problème visuel, décrivez ce qui manque et sur quelle page. Pour une action refusée, gardez le libellé exact et l’heure. Ce relevé servira à choisir un essai utile et à éviter de revenir plusieurs fois sur le même état sans savoir ce qui a changé.

Préparer une copie et préserver les effets déjà produits

Privilégiez une copie du site avec ses fichiers et sa base actuels, ainsi qu’une sauvegarde restaurable d’avant l’intervention. Neutralisez les paiements, courriels, synchronisations et autres effets externes de la copie avant les essais. Changer seulement son adresse ne suffit pas à empêcher une connexion à un service réel.

Le parcours natif modifie l’état des extensions de la copie depuis l’administration. Il convient si vous pouvez reproduire la fonction dans cet environnement. Une seconde voie facultative utilise Troubleshooting pour composer un jeu de composants dans la session courante ; elle ne crée pas une autre base de données et ne remplace pas cette préparation.

Préservez les ajouts récents du site public. Restaurer une ancienne sauvegarde directement sur une boutique active peut écraser des commandes alors que le problème porte sur un script. Pendant les essais, gardez un relevé de chaque état et du résultat. Si aucune copie n’est disponible, préparez avec le responsable une intervention limitée plutôt que désactiver globalement les deux extensions sur les visiteurs.

Choisir une fonction témoin qui existe dans les états comparés

Identifiez d’abord qui fournit la fonction : WordPress, le thème, l’extension A, l’extension B ou leur combinaison. Si A crée votre formulaire, désactiver A puis constater que le formulaire a disparu n’est pas une preuve de conflit. Pour comparer utilement, conservez le fournisseur et les dépendances nécessaires à la fonction observée.

Exemple fictif : A fournit un formulaire et B modifie le chargement des scripts. Sur la copie, vous pouvez comparer le même formulaire avec A active, puis B active ou inactive, si B n’est pas une dépendance indispensable. Le même compte, la même page et la même consultation doivent servir de témoin. N’envoyez pas le formulaire réel pour observer seulement son affichage.

Si les deux extensions sont obligatoires pour la fonction, une comparaison sans l’une retire volontairement une partie du système. Notez cette limite au lieu de conclure que celle qui reste est défectueuse. Il faudra alors examiner les exigences de versions communes et la procédure de compatibilité des auteurs, avec une copie cohérente de leurs données.

Approche 1 : désactiver un seul composant sur la copie

Ce parcours ne nécessite aucune nouvelle extension. Il demande une copie préparée, l’administration et l’identification du composant que vous pouvez retirer sans faire disparaître la fonction témoin. La désactivation agit sur cette installation : ne confondez pas son écran avec celui du site public.

Une désactivation peut exécuter des actions propres au composant. Elle ne correspond pas à une désinstallation, mais ne garantit pas que tous les réglages et tâches resteront identiques. Gardez donc l’état initial et une sauvegarde avant les essais. Si WordPress interdit la désactivation à cause d’une dépendance, ne contournez pas cette protection dans la base.

1. Dans Extensions installées sur la copie, vérifiez que A fournit toujours la fonction et que ses dépendances nécessaires restent actives.
2. Cliquez sur Désactiver pour B uniquement, si ce retrait est cohérent avec le test prévu.
3. Rechargez la même page témoin et répétez seulement la consultation ou l’action de contrôle neutralisée.
4. Notez le résultat et l’état exact des composants. Réactivez B pour retrouver le point de départ et vérifiez si le symptôme réapparaît.
5. Si l’essai modifie des données ou réglages au-delà de l’état actif, rétablissez la copie cohérente avant une nouvelle comparaison.

Interpréter les résultats sans désigner trop vite une extension fautive

Une différence reproductible lorsque B est activée ou désactivée montre que sa présence participe au scénario observé. Elle ne prouve pas à elle seule que B contient tout le défaut : A peut s’appuyer sur un comportement changé, un réglage d’intégration peut être devenu nécessaire ou un troisième composant peut intervenir.

Comparez aussi les notes de version des deux auteurs. Recherchez une modification de prérequis, de dépendance, de chargement des ressources ou de migration. N’appliquez pas un correctif destiné à une autre version simplement parce que son titre ressemble à votre symptôme. Conservez la référence et le périmètre de tout réglage proposé.

• Si la fonction revient avec B inactive et échoue de nouveau avec B active, gardez cette séquence comme preuve de participation au conflit.
• Si elle reste cassée dans les deux états, examinez A, les autres composants et les changements de données ou d’environnement ; B n’est pas innocentée par un seul essai.
• Si le test n’a plus de sens sans B, marquez la comparaison comme non concluante plutôt que comme une réparation.
• Si le résultat varie sans changement d’état, examinez les caches et les conditions du test avant de multiplier les bascules.

Relever une erreur de navigateur sans relancer une opération métier

Pour une fonction d’affichage ou une interaction dans le navigateur, les outils intégrés peuvent fournir une trace utile. Ouvrez les outils de développement de Chrome sur la page témoin et choisissez Console. Gardez les messages liés au chargement que vous comparez ; le premier message rouge n’est pas automatiquement l’origine de tout le problème.

Le panneau Réseau permet de voir les ressources et appels enregistrés pendant son ouverture. Son option Disable cache concerne le cache du navigateur, pas tous les caches du serveur ou du CDN. Gardez les mêmes conditions entre deux états et restaurez ensuite l’option si vous l’avez changée.

1. Sur la copie, ouvrez Console, rechargez la page témoin et relevez le message, le fichier et la ligne disponibles pour l’erreur pertinente.
2. Dans Réseau, repérez le script ou la requête en échec et notez son statut ainsi que le chemin du composant, sans publier de paramètres privés.
3. Comparez ces observations avec B active puis inactive selon le parcours préparé.
4. Ne renvoyez pas une requête de paiement ou d’envoi depuis les outils. Transmettez seulement les éléments utiles, expurgés des cookies, jetons et données personnelles.

Comparer les versions précédentes seulement dans un état cohérent

Si vous devez savoir laquelle des deux mises à jour a introduit le changement, préparez une copie issue d’une sauvegarde complète antérieure. Elle doit inclure les fichiers et les données correspondantes, avec les effets externes neutralisés. Remettre uniquement un ancien dossier d’extension sur une base déjà migrée ne reconstitue pas cette situation.

À partir du même état initial, une comparaison peut appliquer seulement la mise à jour de A, puis, dans une autre copie ou après restauration de ce point de départ, seulement celle de B. Ces états intermédiaires doivent être autorisés par les exigences des deux auteurs. Une mise à jour couplée peut exiger que les versions avancent ensemble ; un état volontairement non pris en charge n’est pas un témoin valable.

Relevez versions, ordre des étapes et résultat dans chaque branche. Le but est d’obtenir un scénario reproductible à transmettre, pas de conserver une ancienne version sans correctifs sur le site public. Si la sauvegarde n’est pas exploitable ou si les migrations ne peuvent pas être annulées proprement, faites préparer cette comparaison par le responsable technique et poursuivez les observations sur la copie actuelle.

Approche 2 : Troubleshooting comme outil facultatif de session

L’extension autonome Troubleshooting, de Marius L. J., permet de composer temporairement un jeu d’extensions et un thème pour votre session. Sa fiche actuelle indique la version 1.0.2, WordPress 5.8 minimum, PHP 7.1 minimum et des tests déclarés jusqu’à WordPress 7.1.4. Le téléchargement du répertoire est gratuit. Ces indications ne garantissent pas chaque combinaison de composants.

Privilégiez encore la copie préparée. Sur le site actif, limitez cette voie à une consultation sans effet métier attendu, après sauvegarde et vérification de la gestion du cache avec son responsable. L’outil cherche à réserver le changement à votre session ; il ne fournit pas une base séparée et ne neutralise pas les paiements, courriels ou écritures du composant testé.

Installez l’extension depuis sa fiche officielle via Extensions, Ajouter une extension, puis activez-la selon la procédure normale préparée. Si vous avez besoin d’un ZIP parce que le téléchargement serveur échoue, utilisez seulement son paquet officiel. Le parcours suivant doit être quitté explicitement après l’essai. Il n’est pas nécessaire lorsque les comparaisons natives sur la copie suffisent.

Activer le mode de dépannage et vérifier son périmètre

Le compte doit pouvoir accéder à Santé du site et installer le fichier nécessaire au mode. Si l’outil signale un problème d’accès aux fichiers, conservez ce message ; n’ouvrez pas les permissions du site pour forcer sa préparation. Ce parcours reste facultatif et ne remplace pas la copie du site.

Le mode fait apparaître les extensions ordinaires comme inactives et utilise un thème par défaut pour votre session. Avant de tester la fonction, il faut donc remettre dans cette session le thème et les composants qui la fournissent. Une fonction absente dans cette situation initiale peut simplement dépendre de ce qui n’est plus chargé.

1. Ouvrez Outils, Santé du site, puis l’onglet Troubleshooting ajouté par l’extension.
2. Cliquez sur Enable Troubleshooting Mode, ou sa traduction affichée, et attendez le tableau de bord de la session de dépannage.
3. Vérifiez la présence de l’indication du mode et du menu Troubleshooting Mode dans la barre d’administration.
4. Si le mode n’est pas clairement actif ou si l’état affiché paraît incohérent, quittez-le et revenez au parcours natif sur copie. Ne poursuivez pas en supposant que vos changements sont isolés.

Reconstituer le jeu nécessaire puis comparer le second composant

Le menu Troubleshooting Mode de la barre d’administration permet de choisir le thème et d’activer individuellement les extensions pour la session. Utilisez-le pour retrouver le fournisseur de la fonction et ses dépendances. Évitez une activation de tout l’ensemble qui ferait perdre le bénéfice de cette comparaison.

Les extensions indispensables, souvent appelées mu-plugins, restent chargées selon leur fonctionnement. Du code de l’hébergeur ou d’autres couches peut donc continuer à agir. Un succès dans cette session ne prouve pas que le même scénario aboutit pour un visiteur anonyme, dans un autre thème ou avec toutes les autres intégrations.

1. Dans le menu du mode, rétablissez le thème qui appartenait à votre point de départ si sa présence est nécessaire au test.
2. Activez A et les dépendances nécessaires dans la session, puis vérifiez que la fonction témoin existe.
3. Faites le contrôle préparé, puis ajoutez B dans cette même session et comparez une seule nouvelle fois.
4. Notez l’état, le thème et le résultat. Si une dépendance ou un composant indispensable rend la comparaison impossible, marquez-la comme non concluante et préparez un essai cohérent sur copie.

Quitter le mode et contrôler l’état normal

Le retour hors du mode est une étape du diagnostic. Le fait de fermer un onglet ne suffit pas à documenter l’état final du site. Quittez explicitement le mode, puis comparez les extensions et le thème à votre relevé initial. Cela permet aussi de distinguer un résultat limité à votre session d’un fonctionnement normal rétabli.

La documentation de Troubleshooting signale que certains caches peuvent ne pas respecter complètement ses indications. Si une page semble conserver l’apparence du test, faites vérifier le cache concerné et une purge limitée selon la procédure de son responsable. Ne désactivez pas durablement les protections ou tous les caches pour masquer cet écart.

1. Depuis le menu de la barre d’administration ou l’onglet de Santé du site, utilisez Disable Troubleshooting Mode.
2. Vérifiez que l’indication du mode a disparu et contrôlez le thème ainsi que l’état normal des composants.
3. Consultez la page témoin dans le contexte prévu pour le site normal ; notez le résultat séparément du test de session.
4. Désactivez l’outil temporaire lorsque son usage est terminé. Les écritures et effets déjà produits pendant les essais demandent leur propre récupération ; quitter le mode ne les annule pas.

Appliquer la correction établie avec les versions correspondantes

Une fois le scénario reproduit, choisissez une correction expliquée par l’auteur pour les versions concernées : réglage précis de compatibilité, mise à jour corrective ou combinaison maintenue. Vérifiez son périmètre sur la copie. Un extrait de code destiné à un autre produit ou une modification de fichier central ne constitue pas un correctif générique au conflit.

Si une version corrective officielle est disponible, sauvegardez l’état de la copie, puis mettez à jour ce seul composant depuis sa ligne dans Extensions installées ou par son paquet officiel vérifié. Refaites exactement la séquence qui échouait. Si un réglage est proposé, notez son menu, sa valeur initiale et sa valeur cible selon la documentation propre au produit ; ne changez pas simultanément plusieurs fonctions.

Une désactivation temporaire de B peut aider à préserver un service, mais son rôle doit être examiné avant d’appliquer cette décision au public. Un composant de connexion, de sécurité ou de traitement de commandes ne se retire pas simplement parce qu’un affichage revient sur la copie. Préparez les conséquences, la durée et le retour avec le responsable. Ne maintenez pas un ancien paquet vulnérable comme solution définitive.

Valider la correction et transmettre un dossier reproductible

Après réussite sur la copie, appliquez le changement retenu dans la fenêtre préparée sur le site actif et contrôlez les mêmes fonctions. Vérifiez l’administration, la page témoin et les intégrations nécessaires. Conservez les versions finalement utilisées et l’état du thème, puis vérifiez le comportement attendu pour les visiteurs concernés.

Pour solliciter les auteurs, fournissez un scénario court : versions initiales et finales, fonction attendue, action exacte, état de A et B, résultat avec et sans le composant comparé. Ajoutez l’erreur Console, Réseau ou serveur utile, avec son heure, après retrait des données privées. Indiquez si le résultat provient d’une copie ou d’une session Troubleshooting et quelles couches n’étaient pas neutralisées.

Le dossier doit permettre de reproduire le cas sans interpréter une capture isolée. Un test non concluant reste une information à conserver ; il ne justifie pas une accusation ni une restauration générale. Gardez la sauvegarde et le plan de retour adaptés aux données qui ont évolué. La résolution est acquise lorsque la fonction et les dépendances nécessaires fonctionnent dans l’état final prévu, au-delà du simple retour d’un bouton.

Rejouer les quatre couples sur la même page témoin

Dans la recette locale, l’extension A produit un lien de document et l’extension B peut modifier son libellé. Le lien apparaît avec A1 et B1, avec A2 et B1, puis avec A1 et B2. Il disparaît lorsque les deux versions 2 sont chargées ensemble. WordPress a rendu le même bloc de code court dans chacun des cas. Les en-têtes des extensions confirment les versions chargées et la comparaison du HTML confirme la présence du lien. Le retour à A1 et B1 rend de nouveau le même lien.

Pour reproduire ce contrôle sur une copie, choisissez une fonction que les deux extensions peuvent laisser visible dans chaque couple. Notez la page, l’action exacte et le résultat attendu avant de commencer. Par exemple, ouvrez une fiche avec un compte de test et vérifiez si le lien de téléchargement apparaît puis mène au document d’essai. Si la désactivation d’une extension supprime toute la fonction, passez à la comparaison des versions et gardez les deux extensions actives.

Si vous utilisez WP-CLI, relevez les versions actives sur la copie avant chaque essai. Depuis le dossier de cette installation, exécutez la commande suivante et notez les deux lignes correspondant à vos extensions. La liste ne remplace pas le contrôle de la fonction témoin. En multisite, relevez aussi les extensions activées au niveau du réseau.

1. Testez d’abord le couple qui fonctionnait, si vous disposez d’un état compatible des fichiers et de la base. Notez les deux versions dans Extensions installées et le résultat de la fonction témoin.
2. Changez seulement A, puis refaites l’action avec le même compte, la même page et les mêmes données. Relevez le résultat et l’heure de l’essai.
3. Changez B pour retrouver le couple récent, refaites le test, puis revenez à A dans sa version précédente pour vérifier l’autre combinaison.
4. Restaurez l’instantané de la copie qui correspond à votre état de départ. Vérifiez le couple de versions et le résultat témoin. Conservez les quatre observations avant de choisir un correctif.

wp plugin list --status=active --fields=name,version --format=table --skip-update-check

Adapter la comparaison quand une mise à jour change la base

Si une mise à jour lance une migration de données, préparez une copie cohérente pour chaque couple que vous pouvez constituer à partir d’un même instantané. Rejouez les mises à jour dans l’ordre retenu et attendez la fin des migrations avant de comparer. Un résultat obtenu en remettant un ancien fichier au-dessus d’un nouveau schéma peut être celui d’un état intermédiaire impossible à maintenir. Consignez le couple que vous avez pu reconstruire, l’état de la migration et les cases qui restent sans résultat.

Dans le banc, les deux extensions d’essai utilisent un bloc de code court et un filtre, avec des données stables. Pour une commande, un abonnement ou un formulaire réel, travaillez avec des données fictives et vérifiez les effets déjà produits. Lorsque l’action demande un service externe, privilégiez le mode de test de ce service ou un scénario qui s’arrête avant l’envoi. Le point de comparaison reste le même pour tous les couples.

Choisir la correction à partir du résultat observé

Si la fonction échoue avec A2 et B1 ainsi qu’avec A2 et B2, transmettez ces résultats au mainteneur de A, avec les versions exactes et les étapes sur la copie. Si les deux versions récentes fonctionnent séparément avec une ancienne version de l’autre extension et que seul le couple récent échoue, transmettez les quatre résultats aux deux mainteneurs. En attendant un correctif compatible, préparez sur la copie le couple retenu et validez aussi les autres fonctions que les extensions partagent. Toute restauration durable se décide après comparaison des fichiers, de la base et des opérations intervenues depuis la mise à jour.