Conflit plugin SEO Elementor ou Divi : isoler la cause en 4 étapes

Conflit plugin SEO Elementor : ce que décrivent les forums

Le conflit plugin SEO Elementor revient sans cesse sur les forums de WordPress.org, avec une vingtaine de sujets en six semaines. Les messages se ressemblent : « erreur serveur à la publication dans Elementor quand l'extension SEO est active », « la dernière version casse Divi 5 », « le constructeur Divi ne se charge plus ». Le point de départ est presque toujours une mise à jour récente, de l'extension SEO, du constructeur ou des deux.

Il y a une raison à cela. Une extension SEO s'installe dans l'éditeur. Elle y ajoute un panneau, lit le contenu de la page pour proposer un titre ou une description, et intervient au moment de l'enregistrement. Un constructeur de pages fait la même chose, en plus lourd. Quand l'un change sa façon de charger ses scripts ou d'enregistrer, l'autre peut recevoir une réponse qu'il n'attend pas. Une erreur PHP donne alors une erreur 500, et une erreur JavaScript bloque l'éditeur sur son écran de chargement.

• Erreur serveur ou erreur 500 au clic sur Publier ou Mettre à jour.
• Constructeur bloqué sur l'écran de chargement, sans message.
• Page enregistrée, mais l'ancienne version reste affichée sur le site.
• Panneau de l'extension SEO vide ou absent dans l'éditeur.

Ce qui relève de l'extension SEO, et ce qui relève du constructeur

Il faut le dire clairement : aucune extension SEO ne corrige les bugs d'un constructeur de pages, et nexya non plus. Son module SEO s'occupe des titres et des descriptions, avec une proposition tirée du texte de la page, ainsi que du sitemap, du schema et du fichier llms.txt. Il ne prend pas en charge le fonctionnement interne d'Elementor ou de Divi.

Avec Elementor, nexya fait deux choses précises. Le cache de page de nexya Pro se vide quand on enregistre dans Elementor. Le module Element, gratuit, fournit seize widgets Elementor pour afficher des champs personnalisés NCF ou ACF : répéteurs en cartes, en onglets ou en tableaux, galeries, chiffres clés, équipes, chronologies, cartes. Pour Divi, nexya ne propose rien de particulier.

Ce que nexya peut vous apporter dans un tel conflit, c'est surtout une manière propre de chercher la cause : couper un seul module, consulter ce qui a changé, revenir à la version précédente d'une extension.

Un module éteint n'enregistre rien : aucun de ses hooks ne tourne sur le site.

Lire l'erreur avant de désactiver quoi que ce soit

Désactiver des extensions au hasard fait perdre du temps et efface parfois les traces utiles. Notez d'abord le symptôme exact et le moment où il est apparu.

Si l'éditeur reste bloqué au chargement, ouvrez la console du navigateur (F12, onglet Console) et rechargez la page. Le nom de fichier qui apparaît dans l'erreur rouge indique souvent l'extension en cause. Pour une erreur serveur à l'enregistrement, activez le journal de débogage de WordPress (WP_DEBUG et WP_DEBUG_LOG dans wp-config.php), recommencez l'opération, puis lisez wp-content/debug.log. Une erreur fatale y donne le chemin du fichier et le numéro de ligne.

Le journal d'activité de nexya vous aide à reconstituer la chronologie. Il indique qui a modifié quoi, avec l'état d'avant et celui d'après. Si le constructeur fonctionnait encore mardi et plus du tout mercredi, c'est là que vous verrez ce qui a bougé entre-temps.

• Console du navigateur : erreur JavaScript, nom du fichier en cause.
• debug.log : erreur PHP fatale, chemin et ligne.
• Journal d'activité : ce qui a changé juste avant la panne.

Isoler un conflit entre l'extension SEO et le constructeur

1. 1

   Relever l'erreur et la chronologie

   Ouvrez la console du navigateur et le fichier debug.log, puis consultez le journal d'activité pour voir ce qui a changé juste avant que le constructeur cesse de fonctionner.

   
2. 2

   Éteindre le seul module SEO

   Désactivez le module SEO depuis le hub et laissez les autres modules allumés. Rechargez le constructeur. S'il fonctionne de nouveau, le module était en cause. Sinon, rallumez-le et testez le suivant.

   
3. 3

   Vider les caches avant de conclure

   Le cache de nexya Pro se vide à l'enregistrement dans Elementor, et celui de Cloudflare avec lui. Videz à la main tout autre cache, puis vérifiez la page dans une fenêtre privée.

   
4. 4

   Revenir en arrière et signaler

   Remettez en place la version précédente de l'extension en cause depuis le module Maintenance. Envoyez ensuite aux deux éditeurs les versions installées, le symptôme et le message d'erreur.

   

Isoler la cause sans couper tout le site

La méthode classique consiste à désactiver toutes les extensions sauf le constructeur, puis à les réactiver une par une. Sur un site en production, cela coupe aussi le formulaire de contact, la bannière cookies et les redirections pendant toute la recherche.

Dans nexya, chaque fonction est un module que l'on active ou désactive depuis le hub. Vous pouvez donc éteindre seulement le module SEO et laisser tourner les cookies, les e-mails et la sécurité. Un module éteint n'enregistre aucun hook : il ne charge plus rien dans l'éditeur et n'intervient plus à l'enregistrement. Si le constructeur repart, vous avez trouvé le module en cause. Sinon, rallumez-le et passez au suivant, par exemple Element si l'erreur apparaît sur une page qui contient ses widgets.

Pour les autres extensions, le mode de dépannage de l'extension Health Check & Troubleshooting désactive les extensions pour votre seule session, sans toucher à ce que voient les visiteurs. Testez aussi avec un thème par défaut lorsque Divi est utilisé comme thème.

Le cache n'est pas un bug d'Elementor

Une partie des sujets « l'extension casse Elementor » décrit en réalité un problème de cache. La page s'enregistre bien, mais le visiteur voit encore l'ancienne version. Le constructeur n'y est pour rien : c'est une copie gardée trop longtemps quelque part.

Le cache de page de nexya Pro se vide quand on enregistre dans Elementor. Depuis la version 1.2.31, le cache de Cloudflare se vide en même temps que celui de nexya, en entier ou seulement pour les adresses de la page modifiée. Si vous utilisez un autre cache, de l'hébergeur ou d'une autre extension, videz-le à la main avant de conclure à un conflit. Testez ensuite dans une fenêtre de navigation privée.

Revenir à la version précédente, puis signaler le problème

Quand la panne suit une mise à jour, la solution la plus rapide est souvent de revenir à la version d'avant, le temps que l'éditeur publie un correctif. Le module Maintenance de nexya conserve la version précédente de chaque extension et de chaque thème juste avant la mise à jour, et la remet en place en un clic. Cette fonction est gratuite. Dans nexya Pro, une mise à jour qui casse le site est annulée automatiquement et l'administrateur reçoit un e-mail.

Signalez ensuite le problème aux deux éditeurs, celui de l'extension SEO et celui du constructeur. Un rapport utile donne les versions exactes de WordPress, de PHP, du constructeur et de l'extension SEO, le symptôme précis, l'erreur relevée dans la console ou dans debug.log, et précise si le problème disparaît quand l'extension ou le module est désactivé. Avec ces éléments, l'équipe concernée peut reproduire le problème au lieu de vous demander de tout réinstaller.

• Versions de WordPress, de PHP, du constructeur et de l'extension SEO.
• Symptôme précis et action qui le déclenche.
• Message d'erreur copié depuis la console ou depuis debug.log.
• Résultat du test avec l'extension ou le module désactivé.