# Un compte client qui ignore HPOS : le template resté sur l’ancien statut

> Après l'activation du stockage optimisé des commandes WooCommerce, un gabarit de l'éditeur de site continue d'afficher un statut de commande obsolète. Le diagnostic tient à une requête restée figée sur l'ancien format.

- Auteur : WordPress Développement
- Publié le : 2022-11-09
- Mis à jour le : 2026-09-30
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/compte-client-hpos-template-statut-ancien/

## L’essentiel

- Repérer une requête qui interroge encore la table posts pour des commandes
- Comprendre pourquoi HPOS change la source de vérité des données
- Corriger le point d'accès sans casser le reste du site

Un client s'étonne : sa commande passée la veille affiche toujours le statut « en attente de paiement » sur son espace personnel, alors que le paiement a bel et bien été validé et que le statut réel, visible depuis l'administration WooCommerce, est bien « terminée ». Le site venait tout juste d'activer le stockage optimisé des commandes, cette fonctionnalité disponible depuis peu chez WooCommerce, qui déplace les données de commande hors des tables historiques de contenu WordPress.

Le gabarit de compte client affiché sur ce site n'était pas un gabarit WooCommerce standard, mais une composition personnalisée assemblée dans l'éditeur de site, intégrant un bloc HTML personnalisé qui interrogeait directement la base de données pour afficher un résumé de la dernière commande. Ce détail d'implémentation, invisible en apparence, est devenu la source exacte du problème.

## Symptôme

Le statut affiché sur le gabarit personnalisé restait bloqué sur l'état antérieur à la validation du paiement, alors que l'écran WooCommerce natif de suivi de commande, lui, affichait correctement le statut à jour. Seule cette composition maison dans l'éditeur de site montrait un décalage.

## Diagnostic

Le bloc HTML personnalisé du gabarit contenait un appel PHP embarqué qui récupérait le statut de commande via `get_post_status( $commande_id )`, fonction qui interroge directement la table `wp_posts`. Une fois le stockage optimisé des commandes activé, WooCommerce ne considère plus systématiquement cette table comme source de vérité pour les commandes : les données réelles vivent désormais dans des tables dédiées, gérées par la nouvelle couche d'abstraction de données de WooCommerce.

```
// Ancien code, resté figé sur la table posts
$statut = get_post_status( $commande_id );

// Version corrigée, passant par l'objet commande WooCommerce
$commande = wc_get_order( $commande_id );
$statut   = $commande ? $commande->get_status() : '';
```

La fonction `wc_get_order()` renvoie un objet commande qui s'appuie sur la couche d'abstraction de données de WooCommerce, capable de lire la bonne source quel que soit le mode de stockage actif sur le site, contrairement à un accès direct à `wp_posts`.

> L'essentiel à retenir : Repérer une requête qui interroge encore la table posts pour des commandes ; Comprendre pourquoi HPOS change la source de vérité des données ; Corriger le point d'accès sans casser le reste du site

## Correctif

Le bloc HTML personnalisé du gabarit a été remplacé par un appel systématique à `wc_get_order()`, en s'assurant également que l'objet retourné n'était jamais nul avant d'en lire le statut, afin de gérer proprement le cas d'une commande supprimée entre-temps.

- Remplacement de tous les accès directs à `wp_posts` concernant des commandes par les fonctions d'API WooCommerce dédiées.
- Vérification systématique du retour de `wc_get_order()`, qui peut renvoyer faux si l'identifiant ne correspond à aucune commande valide.
- Recherche, dans le reste du thème, d'autres blocs HTML personnalisés susceptibles de contenir le même type d'accès direct désormais obsolète.

## Prévention

Ce type de décalage n'est pas propre à l'éditeur de site : il aurait pu survenir sur n'importe quel gabarit PHP classique contenant le même code direct. Ce qui a rendu le diagnostic plus long ici, c'est que le gabarit fautif était une composition récente de l'éditeur de site, moins surveillée par l'équipe que les gabarits WooCommerce natifs, déjà mis à jour par les mainteneurs de l'extension pour gérer correctement les deux modes de stockage.

### Points à vérifier avant toute activation du stockage optimisé

- Inventorier tous les blocs HTML personnalisés du site contenant du code PHP embarqué lié aux commandes.
- Privilégier systématiquement les fonctions d'API WooCommerce plutôt qu'un accès direct aux tables de la base de données.
- Tester le parcours client complet, y compris les gabarits d'éditeur de site, avant de considérer la migration terminée.

> Un changement de source de vérité côté données ne pardonne aucun raccourci pris ailleurs dans le thème, même dans un simple bloc HTML inséré au détour d'un gabarit.

## En résumé

Le décalage de statut observé sur ce gabarit d'éditeur de site venait d'un accès direct à la table `wp_posts`, resté valide avant l'activation du stockage optimisé des commandes mais devenu incorrect une fois cette fonctionnalité activée. Le correctif, simple une fois le diagnostic posé, rappelle qu'un tel changement de stockage impose de vérifier l'ensemble des points d'accès aux données de commande, y compris ceux logés dans des blocs personnalisés faciles à oublier.