# Le schéma de wp_postmeta lu à travers la donnée _elementor_data

> Une seule ligne de métadonnée porte toute la structure d'une page Elementor. Comprendre son format éclaire des choix de performance souvent mal expliqués.

- Auteur : WordPress Développement
- Publié le : 2020-03-26
- Mis à jour le : 2020-03-26
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/schema-wp-postmeta-elementor-data/

## L’essentiel

- Toute la mise en page tient dans une seule valeur meta
- Le format est un tableau PHP sérialisé en JSON
- Une page complexe peut peser plusieurs centaines de Ko

Une page construite avec Elementor, une fois enregistrée, ne laisse presque aucune trace dans la structure habituelle de WordPress. Pas de dizaines de lignes dans `wp_postmeta`, pas de shortcodes empilés dans `post_content` : tout tient dans une seule clé, `_elementor_data`, qui contient l'intégralité de la structure de la page sous forme de tableau sérialisé.

Ce choix architectural, présent depuis les premières versions publiques d'Elementor, mérite qu'on s'y attarde, parce qu'il explique à la fois des qualités (portabilité, versionnage possible) et des désagréments bien réels une fois qu'un site grossit.

## Ce que contient réellement la ligne

Ouvrir la table `wp_postmeta` pour un post donné et filtrer sur `meta_key = '_elementor_data'` renvoie une seule ligne, dont la colonne `meta_value` contient une chaîne JSON représentant un tableau d'éléments imbriqués. Chaque élément — section, colonne, widget — possède un identifiant unique de sept caractères, un type (`elType`), des réglages (`settings`) et, le cas échéant, des enfants (`elements`).

```
[
  {
    "id": "7f3a921",
    "elType": "section",
    "settings": { "layout": "boxed" },
    "elements": [
      {
        "id": "b12cd44",
        "elType": "column",
        "elements": [
          {
            "id": "9e001aa",
            "elType": "widget",
            "widgetType": "heading",
            "settings": { "title": "Bienvenue" }
          }
        ]
      }
    ]
  }
]
```

Cette structure arborescente est exactement ce que l'éditeur manipule visuellement : déplacer un widget dans l'interface revient, en coulisses, à déplacer un objet dans ce tableau puis à réenregistrer l'intégralité de la valeur.

## Pourquoi une seule ligne plutôt que plusieurs

> L'essentiel à retenir : Toute la mise en page tient dans une seule valeur meta ; Le format est un tableau PHP sérialisé en JSON ; Une page complexe peut peser plusieurs centaines de Ko

Un choix alternatif aurait consisté à répartir chaque élément dans sa propre ligne de métadonnée, avec des références croisées. Elementor ne fait pas ce choix : il sérialise tout l'arbre en une seule fois. L'avantage immédiat est la simplicité de lecture et d'écriture : un seul `get_post_meta()` suffit pour récupérer la page entière, et un seul `update_post_meta()` pour la sauvegarder, sans transaction complexe à orchestrer entre plusieurs lignes.

La contrepartie apparaît dès qu'une page grossit. Un aperçu de projet mené sur une page d'accueil comportant une trentaine de sections et une centaine de widgets a montré une valeur `_elementor_data` dépassant 300 Ko de texte brut. Chaque enregistrement dans l'éditeur réécrit cette valeur en entier, même si un seul mot a changé dans un titre.

## Ce que cela implique pour la requête de lecture

Quand une page s'affiche côté public, WordPress charge cette métadonnée via l'objet `$post` puis Elementor la décode avec `json_decode()` avant de parcourir récursivement l'arbre pour générer le HTML final. Cette étape de décodage et de parcours a un coût CPU réel, proportionnel à la taille de l'arbre, ce qui explique en partie pourquoi la mise en cache d'objets (via un cache de type Redis ou Memcached) apporte un gain mesurable sur des pages Elementor volumineuses : elle évite de refaire ce décodage à chaque visite.

- La métadonnée est lue en une fois, jamais fragment par fragment.
- Le décodage JSON puis le parcours récursif ont un coût lié à la taille de l'arbre.
- La mise en cache d'objets réduit la fréquence de ce traitement, pas sa nature.

## Ce qu'il ne faut pas faire avec cette donnée

Modifier directement la valeur `_elementor_data` depuis phpMyAdmin, sans passer par l'éditeur, est une tentation dangereuse : un simple guillemet mal échappé rend le JSON invalide et la page cesse de s'afficher correctement, parfois sans message d'erreur explicite. WordPress propose des fonctions comme `wp_slash()` pour ce genre de manipulation programmatique, mais l'édition manuelle en base reste réservée à des cas d'urgence bien maîtrisés.

> Sur un projet où une modification en base a corrompu la structure, revenir à une sauvegarde a pris moins de temps que de tenter de réparer le JSON à la main.

## Pour aller plus loin

Ce format en une seule métadonnée sérialisée n'est pas propre à Elementor : d'autres constructeurs de pages font des choix similaires. Comprendre cette mécanique aide surtout à interpréter correctement les recommandations de performance qu'on lit ici ou là, et à ne pas confondre un problème d'optimisation de requêtes SQL classique avec un problème de taille de structure JSON, qui appelle des solutions très différentes.