# HPOS et le widget Elementor Products : ce qui casse après activation

> Un widget WooCommerce Builder qui lit encore une métadonnée de commande à l'ancien format dès que l'option expérimentale de stockage haute performance des commandes est activée.

- Auteur : WordPress Développement
- Publié le : 2022-11-09
- Mis à jour le : 2026-09-30
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/hpos-widget-elementor-products-metadonnee-ancien-format/

## L’essentiel

- HPOS reste une option expérimentale à cette date, pas encore un standard
- Un widget qui lit directement les tables postmeta casse en silence
- La couche de compatibilité CRUD WooCommerce évite ce piège

WooCommerce propose, depuis la version 7.1, une option expérimentale encore réservée aux environnements de test : le stockage des commandes dans des tables dédiées plutôt que dans la table générique `wp_posts`, un chantier connu sous le nom de High-Performance Order Storage. Activée par curiosité sur un site de recette, cette bascule a immédiatement fait apparaître un champ vide sur le widget **Products** du WooCommerce Builder d'Elementor Pro, censé afficher un badge personnalisé de fidélité sur les commandes récentes du client connecté.

Ce diagnostic ne traite pas de la migration des extensions tierces vers HPOS en général, ni de la configuration complète de cette fonctionnalité encore expérimentale à cette date : il se concentre sur ce qui a cassé, précisément, sur ce widget.

## Symptôme : un badge qui n'affiche plus rien

Le badge de fidélité, calculé à partir d'une métadonnée personnalisée stockée sur la commande (`_client_fidele`, ajoutée par un plugin maison), s'affichait normalement avant l'activation de l'option expérimentale HPOS depuis WooCommerce > Réglages > Avancé > Fonctionnalités. Une fois l'option activée en environnement de recette, le badge disparaît silencieusement, sans erreur PHP visible dans les logs.

## Diagnostic : un accès direct à la table, pas à la commande

Le code du widget personnalisé, écrit avant l'existence de HPOS, allait chercher la métadonnée directement en base via une requête `SQL` ciblant `wp_postmeta`, plutôt que d'utiliser les fonctions d'accès fournies par WooCommerce :

```
// Ancien code, incompatible HPOS :
global $wpdb;
$valeur = $wpdb->get_var( $wpdb->prepare(
    "SELECT meta_value FROM {$wpdb->postmeta}
     WHERE post_id = %d AND meta_key = '_client_fidele'",
    $order_id
) );
```

> L'essentiel à retenir : HPOS reste une option expérimentale à cette date, pas encore un standard ; Un widget qui lit directement les tables postmeta casse en silence ; La couche de compatibilité CRUD WooCommerce évite ce piège

Une fois HPOS activé, les commandes ne sont plus stockées comme des lignes de `wp_posts` avec leurs métadonnées dans `wp_postmeta` : elles vivent dans des tables dédiées (`wp_wc_orders` et `wp_wc_orders_meta`). La requête directe du widget continue de chercher dans `wp_postmeta`, une table où la métadonnée n'existe simplement plus pour les commandes créées après la bascule.

### La bonne pratique, déjà documentée par WooCommerce

- Utiliser `wc_get_order( $order_id )` pour récupérer un objet commande, quelle que soit la table de stockage active
- Lire une métadonnée personnalisée via `$order->get_meta( '_client_fidele' )`, jamais via une requête SQL directe
- Écrire une métadonnée via `$order->update_meta_data()` suivi de `$order->save()`, plutôt que `update_post_meta()`

## Correctif appliqué au widget

```
$order  = wc_get_order( $order_id );
$valeur = $order ? $order->get_meta( '_client_fidele' ) : '';
```

Cette réécriture, conforme à la couche d'abstraction CRUD de WooCommerce disponible depuis plusieurs années déjà, fonctionne indifféremment que HPOS soit activé ou non : c'est précisément le rôle de cette couche que d'isoler le code métier du format de stockage réel des données.

> Conseil maison : tout widget Elementor personnalisé qui interagit avec des commandes WooCommerce devrait systématiquement passer par les fonctions CRUD officielles, même si HPOS reste optionnel à ce jour. C'est la seule garantie de rester compatible le jour où l'option deviendra un standard plus largement adopté.

## Portée du problème sur ce site

Un audit du code du widget et des snippets maison du site a permis de recenser deux autres emplacements utilisant le même schéma d'accès direct à `wp_postmeta` pour des données de commande, tous deux corrigés avant d'envisager une éventuelle activation de HPOS en production, une décision reportée à une phase ultérieure du projet le temps que l'option gagne en maturité.

## En résumé

Tester une fonctionnalité encore expérimentale comme HPOS en environnement de recette a permis de détecter, avant toute mise en production, un code de widget qui contournait la couche d'abstraction WooCommerce. Ce type de test précoce évite une mauvaise surprise le jour où l'option deviendra le comportement par défaut.