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.
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_postsconcernant 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.
