# « La méta existe mais s’affiche vide » : un cache mal amorcé sous Elementor

> Un champ personnalisé lu juste après son écriture peut tomber sur un cache non rafraîchi. Diagnostic du priming du cache de métadonnées sous Elementor.

- Auteur : WordPress Développement
- Publié le : 2021-10-06
- Mis à jour le : 2021-10-06
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/meta-existe-affiche-vide-cache-elementor/

## L’essentiel

- La valeur existe en base mais le cache renvoie une ancienne version
- Le priming du cache de métadonnées explique ce décalage
- Un rafraîchissement ciblé du cache résout le symptôme

« La valeur est bien là dans phpMyAdmin, mais le widget affiche un champ vide. » Ce symptôme, remonté sur un projet où un script d'import mettait à jour une métadonnée juste avant l'affichage d'une page, a de quoi dérouter : la donnée existe indiscutablement en base, mais l'affichage front la traite comme absente. La cause se trouve dans un mécanisme discret de WordPress, le cache de métadonnées, rarement évoqué mais responsable d'un nombre surprenant de bogues de ce type.

Retracer précisément ce qui se passe entre l'écriture d'une métadonnée et sa lecture par un widget Elementor permet de comprendre pourquoi ce genre de décalage survient, et comment l'éviter sans rustine hasardeuse.

## Le contexte du bogue

Le projet en question exécutait un script d'import, déclenché par une tâche planifiée WP-Cron, qui mettait à jour une métadonnée de prix sur plusieurs centaines d'articles via des appels directs à `update_post_meta()`. Immédiatement après cet import, un widget Elementor personnalisé, chargé de lire cette même métadonnée pour l'afficher, renvoyait parfois une valeur vide ou une ancienne valeur, uniquement sur certaines requêtes suivant de très près l'exécution du script.

## Diagnostic : le cache d'objets et son amorçage

> L'essentiel à retenir : La valeur existe en base mais le cache renvoie une ancienne version ; Le priming du cache de métadonnées explique ce décalage ; Un rafraîchissement ciblé du cache résout le symptôme

WordPress maintient un cache interne des métadonnées, documenté dans la [référence de update_meta_cache()](https://developer.wordpress.org/reference/functions/update_meta_cache/), qui précharge en une seule requête SQL toutes les métadonnées d'un lot de posts, plutôt que d'exécuter une requête séparée à chaque appel de `get_post_meta()`. Ce mécanisme, appelé *priming* du cache, s'exécute normalement lors de la requête principale (`WP_Query`), qui précharge les métadonnées des posts qu'elle vient de récupérer.

Le problème apparaît quand un script tiers, exécuté hors du cycle normal d'une requête WordPress complète — typiquement dans une tâche WP-Cron isolée — modifie des métadonnées sans jamais invalider ou raffraîchir le cache d'objets persistant, si le site utilise un cache externe comme Redis. La requête suivante qui affiche la page peut alors récupérer, depuis ce cache persistant, une version antérieure de la métadonnée, tant que le cache concerné n'a pas expiré ou été explicitement invalidé.

## Correctif : invalider explicitement après l'écriture

La fonction `update_post_meta()` invalide normalement elle-même le cache pour la clé concernée, sur le post concerné, dans le même processus PHP. Le problème observé venait en réalité d'un script qui écrivait la métadonnée via une requête SQL directe, en contournant l'API WordPress pour des raisons de performance sur un import de masse, ce qui empêchait toute invalidation automatique du cache.

```
// À éviter : écriture directe qui contourne le cache
global $wpdb;
$wpdb->update( $wpdb->postmeta, array( 'meta_value' => $prix ), array(
    'post_id'  => $post_id,
    'meta_key' => 'prix_produit',
) );

// Correctif : invalider explicitement après l'écriture directe
wp_cache_delete( $post_id, 'post_meta' );
```

Ce simple appel à `wp_cache_delete()`, ajouté juste après chaque écriture directe en base, a suffi à éliminer le symptôme : la lecture suivante de la métadonnée repart d'une requête fraîche plutôt que d'une valeur mise en cache avant la modification.

## Ce qu'il faut retenir pour éviter ce piège

- Toute écriture directe en base qui contourne l'API WordPress doit s'accompagner d'une invalidation manuelle du cache concerné.
- Privilégier `update_post_meta()` plutôt qu'une requête SQL directe reste la solution la plus sûre, sauf contrainte de performance réelle et mesurée.
- Un décalage entre valeur en base et valeur affichée, juste après une écriture, doit toujours faire suspecter un problème de cache avant un bogue applicatif.

> Une valeur correcte en base et une valeur incorrecte à l'affichage pointent presque toujours vers une couche de cache, jamais vers la donnée elle-même.

## En résumé

Ce type de décalage, discret mais déroutant, rappelle qu'écrire dans WordPress ne se limite jamais à modifier une ligne en base : il faut aussi tenir compte des couches de cache qui s'intercalent entre l'écriture et la lecture. Le fonctionnement des Dynamic Tags Elementor eux-mêmes, qui exploitent ces métadonnées pour un affichage dynamique, répond à une mécanique distincte qui mériterait son propre éclairage.