Deux façons de stocker une page construite visuellement s’opposent depuis longtemps dans l’écosystème WordPress : la première encode chaque bloc sous forme de shortcode imbriqué dans post_content, la seconde stocke une structure de données à part, généralement en JSON, dans une métadonnée séparée. Elementor a choisi la seconde voie dès ses premières versions publiques, un choix qui mérite d’être expliqué plutôt que simplement constaté.
D’autres constructeurs de pages plus anciens, contemporains ou légèrement antérieurs à Elementor, ont opté pour les shortcodes imbriqués : chaque section, chaque colonne, chaque widget devient un shortcode contenant d’autres shortcodes, le tout empilé dans le contenu de l’article. Comparer les deux approches éclaire des choix qui, sinon, semblent arbitraires.
Ce qu’aurait donné une page Elementor en shortcodes
Un système à base de shortcodes imbriqués aurait pu ressembler à ceci pour une simple section avec un titre :
[section layout="boxed"]
[column width="100"]
[heading title="Bienvenue" size="large"]
[/column]
[/section]Cette syntaxe reste lisible pour un humain habitué au balisage WordPress, mais elle impose un travail de parsing — l’analyse syntaxique du texte pour en extraire une structure exploitable — à chaque affichage de la page, via la fonction do_shortcode() et son moteur d’expressions régulières. Plus la page comporte de niveaux d’imbrication, plus ce travail devient coûteux et fragile : un shortcode mal fermé peut casser toute la structure qui suit.
Ce que change le stockage en JSON
En stockant directement un tableau structuré, sérialisé en JSON dans _elementor_data, Elementor évite cette étape de parsing textuel : la structure de la page est déjà un arbre de données exploitable directement par PHP via json_decode(), sans expression régulière ni risque de balise mal fermée. Le gain principal se situe dans la fiabilité du format : un JSON valide ou invalide se détermine sans ambiguïté, alors qu’un shortcode mal fermé peut produire un résultat partiellement correct, difficile à diagnostiquer.
Le second avantage concerne la portabilité. Exporter un Kit Elementor revient à copier cette structure JSON telle quelle, l’empaqueter, puis la réinjecter sur un autre site. Un système à base de shortcodes imbriqués rendrait cette opération plus délicate, puisque le contenu resterait mélangé au texte de l’article dans post_content, sans séparation nette entre structure et contenu éditorial classique.
Le prix payé : la lisibilité en base brute
Ce choix a un coût direct : ouvrir post_content pour une page Elementor révèle un contenu quasiment vide, remplacé par un court commentaire HTML, alors que la vraie structure vit ailleurs, dans une métadonnée peu lisible sans outil dédié. Un développeur habitué à lire directement le contenu d’une page WordPress dans la base peut se sentir désorienté face à une page Elementor, où tout se joue dans _elementor_data.
- Le contenu visible en base ne reflète plus la structure réelle de la page.
- Un outil d’inspection dédié — ou l’éditeur lui-même — devient nécessaire pour comprendre la mise en page.
- Les recherches en texte brut sur le contenu d’une page deviennent moins fiables sans traitement du JSON.
Un choix cohérent avec l’usage visé
Ce compromis fait sens au regard de l’usage prévu : Elementor cible avant tout une édition visuelle, où la structure change fréquemment par glisser-déposer, jamais par modification manuelle du texte brut. Un format optimisé pour la manipulation programmatique par un éditeur JavaScript sert mieux cet usage qu’un format optimisé pour la lecture humaine directe en base.
Le bon format de stockage dépend toujours de qui, ou de quoi, va le lire en premier : un humain avec un éditeur de texte, ou un programme qui reconstruit une interface.
Pour aller plus loin
Ce choix historique explique aussi pourquoi manipuler directement les données d’une page Elementor en base de données reste une opération à haut risque, réservée à des cas précis et toujours précédée d’une sauvegarde. La manipulation directe de ces données, ses outils et ses limites, mériterait un développement à part entière.
