Contenu Elementor qui disparaît après enregistrement : le diagnostic complet

Ce symptôme revient régulièrement dans mes interventions, et il a une particularité désagréable : Elementor ne signale rien. Pas de message d'erreur, pas d'avertissement. Vous cliquez sur Enregistrer, rien ne bouge à l'écran, et vous découvrez la perte seulement en rouvrant la page.

Cette absence de signal est précisément ce qui rend le diagnostic long. On soupçonne le navigateur, un bloqueur de publicité, le cache, l'hébergeur, la connexion internet — et on peut passer des heures sur ces pistes sans rien trouver, parce que la réponse est ailleurs.

Cet article suit l'ordre dans lequel il faut procéder : d'abord établir où le contenu se perd, ensuite seulement chercher pourquoi.

Étape 1 — Vos données sont-elles en base ?

C'est la première question, et la seule qui compte au départ. Tant que vous ne savez pas si le contenu atteint la base de données, tout le reste est de la spéculation.

Elementor ne stocke pas votre mise en page dans le contenu classique de l'article. Il l'écrit dans une métadonnée nommée _elementor_data, sous forme de JSON. C'est là qu'il faut regarder.

Ouvrez phpMyAdmin depuis votre hébergeur, allez dans l'onglet SQL et lancez cette requête, en remplaçant 123 par l'identifiant de votre page (visible dans l'URL de l'éditeur, paramètre post=) :

SELECT LENGTH(meta_value) AS taille
FROM wp_postmeta
WHERE post_id = 123 AND meta_key = '_elementor_data';

Trois résultats possibles, et chacun oriente vers une cause différente :

• Aucune ligne — Elementor n'a jamais rien écrit. Le problème se situe avant l'enregistrement, côté navigateur.
• Une taille de 2 — la valeur est un tableau vide. Elementor a bien enregistré, mais il croyait la page vide. C'est le cas le plus trompeur : techniquement, l'enregistrement a réussi.
• Une taille de plusieurs milliers — vos données sont là. Le problème est à la lecture, pas à l'écriture.

Étape 2 — Le JSON est-il valide ?

Si la taille est importante mais que la page reste vide à l'ouverture, vérifiez que le JSON n'est pas corrompu. Elementor ne sait pas afficher une structure invalide, et il le fait sans se plaindre : vous obtenez une page blanche, pas un message d'erreur.

SELECT JSON_VALID(meta_value) AS json_ok, LENGTH(meta_value) AS taille
FROM wp_postmeta
WHERE post_id = 123 AND meta_key = '_elementor_data';

Un résultat à zéro signifie que la structure est cassée. Pour voir où, regardez la fin de la chaîne : un JSON Elementor complet se termine toujours par un crochet fermant. S'il s'arrête au milieu d'un mot, l'écriture a été interrompue.

SELECT RIGHT(meta_value, 60) AS fin
FROM wp_postmeta
WHERE post_id = 123 AND meta_key = '_elementor_data';

Vous pouvez aussi mesurer l'ampleur du problème sur l'ensemble du site :

SELECT COUNT(*) FROM wp_postmeta
WHERE meta_key = '_elementor_data' AND JSON_VALID(meta_value) = 0;

Si ce nombre est faible au regard du total, votre site va bien et seules quelques pages sont touchées. S'il est élevé, le problème est systémique.

Étape 3 — Récupérer le travail perdu

Bonne nouvelle : dans la plupart des cas, le contenu n'est pas perdu. WordPress conserve des révisions, et Elementor y enregistre également ses données. Une révision antérieure contient souvent la version intacte.

Listez les révisions de votre page avec la taille de leurs données Elementor :

SELECT p.ID, p.post_date, LENGTH(pm.meta_value) AS taille
FROM wp_posts p
LEFT JOIN wp_postmeta pm
  ON pm.post_id = p.ID AND pm.meta_key = '_elementor_data'
WHERE p.post_parent = 123
ORDER BY p.ID DESC;

Cherchez la révision avec la plus grosse taille : c'est votre travail. Notez son identifiant, puis recopiez ses données vers la page principale.

Faites une sauvegarde de votre base avant cette manipulation — un export de la table wp_postmeta depuis phpMyAdmin suffit, et prend dix secondes.

UPDATE wp_postmeta
SET meta_value = (
  SELECT meta_value FROM (
    SELECT meta_value FROM wp_postmeta
    WHERE post_id = 456 AND meta_key = '_elementor_data'
  ) AS source
)
WHERE post_id = 123 AND meta_key = '_elementor_data';

Remplacez 456 par l'identifiant de la révision et 123 par celui de votre page. La sous-requête imbriquée n'est pas une coquetterie : MySQL refuse de lire et d'écrire dans la même table sans cette précaution.

Ensuite, allez dans Elementor → Outils → Régénérer les fichiers et les données, videz votre cache, et rouvrez la page.

La cause la plus fréquente : un verrou d'édition bloqué

WordPress pose un verrou sur chaque contenu ouvert en édition, pour éviter que deux personnes se marchent dessus. Ce verrou est stocké dans une métadonnée _edit_lock et se libère normalement à la fermeture.

Normalement. Quand une session se termine brutalement — onglet fermé sans attendre, connexion coupée, navigateur qui plante — le verrou peut rester. Elementor le lit, considère que la page est éditée ailleurs, et refuse d'écrire. Silencieusement.

Le signe qui ne trompe pas se voit dans la console du navigateur (touche F12, onglet Console) :

Document is not editable

Pour vérifier les verrous en place :

SELECT post_id, meta_value FROM wp_postmeta WHERE meta_key = '_edit_lock';

La valeur se lit sous la forme horodatage puis identifiant de l'utilisateur. S'il y a de nombreux verrous, ou des verrous anciens sur des pages que personne n'édite, ils ne se libèrent pas correctement. Vous pouvez les purger sans risque — WordPress les recrée à la demande, et ils ne contiennent aucun contenu :

DELETE FROM wp_postmeta WHERE meta_key IN ('_edit_lock', '_edit_last');

Assurez-vous simplement que personne n'est en train d'éditer le site au moment où vous lancez cette requête.

L'autre cause : une erreur JavaScript dans l'éditeur

Elementor fonctionne avec un système interne de commandes : l'enregistrement, le chargement, l'annulation passent tous par le même mécanisme. Si un composant de l'éditeur plante au démarrage, il peut entraîner ce système dans sa chute — et l'enregistrement cesse de répondre.

Ouvrez la console (F12) au chargement de l'éditeur et cherchez les lignes rouges. Ce type de message est révélateur :

TypeError: Cannot read properties of null (reading 'parentElement')

Regardez le nom du fichier indiqué à droite de l'erreur : il désigne le composant fautif. J'ai rencontré ce cas avec la checklist de lancement d'Elementor, dont le plantage empêchait l'éditeur de terminer son initialisation.

Un symptôme secondaire aide à repérer ce problème : le bouton d'enregistrement ne se grise jamais. Normalement, il devient inactif dès que la sauvegarde est confirmée. S'il reste cliquable en permanence, l'éditeur ne reçoit pas la confirmation du serveur — même quand celui-ci a bien enregistré.

Les pistes à ne pas suivre

Sur une intervention récente, j'ai éliminé une à une les hypothèses que tout le monde formule en premier. Autant vous faire gagner ce temps.

• Le bloqueur de publicité. Testez en navigation privée : les extensions y sont désactivées. Si le problème persiste, ce n'est pas ça.
• Le cache. Un plugin de cache n'agit pas dans l'administration WordPress. Il peut affecter l'affichage public d'une page, pas son enregistrement.
• L'hébergeur ou le pare-feu. Vérifiable en trente secondes : ouvrez l'onglet Réseau de la console, filtrez sur admin-ajax et cliquez sur Enregistrer. Un code 200 signifie que la requête est passée et que le serveur a répondu.
• La connexion ou le pays. Si le contenu est bien écrit en base mais vide à l'affichage, le réseau a fait son travail.
• Le navigateur ou l'ordinateur. Si le symptôme se reproduit sur une autre machine, cherchez ailleurs.

Le principe est toujours le même : établissez d'abord où le contenu se perd. Entre le navigateur et la base, il n'y a que trois étapes possibles — la requête part ou non, le serveur écrit ou non, l'éditeur relit ou non. La requête SQL de l'étape 1 tranche entre les trois en quelques secondes.

Comment éviter que cela se reproduise

• Attendez la confirmation avant de fermer. Tant que le bouton d'enregistrement ne se grise pas, l'écriture peut être en cours.
• Un compte par personne. Si plusieurs personnes partagent un même identifiant WordPress, les verrous d'édition deviennent impossibles à attribuer. C'est gratuit à corriger et cela améliore aussi la traçabilité.
• Des sauvegardes automatiques quotidiennes. Les révisions WordPress dépannent, mais elles ne remplacent pas une vraie sauvegarde.
• Surveillez la console de temps en temps. Une erreur JavaScript qui apparaît après une mise à jour est un signal d'alerte précoce, bien avant qu'elle ne casse quelque chose de visible.

En résumé

Dans la grande majorité des cas, le contenu ne disparaît pas : il n'a jamais été écrit, ou il est écrit mais illisible. La distinction se fait en une requête SQL, et elle détermine tout le reste du diagnostic.

Si vos données sont en base, votre travail est presque toujours récupérable — sinon dans la page elle-même, du moins dans l'une de ses révisions.