Pourquoi un template de compte client, construit dans le Site Editor pour un thème bloc compatible WooCommerce, affiche-t-il un statut de commande différent de celui visible dans l’administration ? C’est la question posée par ce client, gérant une boutique en ligne de matériel de randonnée, alors que WooCommerce commence tout juste à expérimenter son nouveau mode de stockage des commandes à haute performance, encore en phase de tests précoces à cette date, loin d’une bascule généralisée sur l’ensemble des boutiques.
Le problème touchait, sur ce projet, un peu plus d’une dizaine de commandes sur plusieurs centaines : un statut affiché comme « en attente de paiement » côté site public, alors que l’administration WooCommerce montrait clairement une commande déjà réglée et expédiée. Rien d’aléatoire dans ce décalage, mais un motif encore difficile à cerner au premier regard.
Symptôme : un décalage limité à certaines commandes précises
Toutes les commandes n’étaient pas concernées, ce qui a d’abord orienté les recherches vers une piste erronée, celle d’un problème de cache. Un examen plus attentif a montré que seules les commandes créées ou modifiées après l’activation d’une extension tierce de gestion des stocks, récemment installée sur cette boutique, présentaient ce décalage.
Diagnostic : deux sources de vérité pour une même donnée
Cette boutique participait, sur demande de l’agence, aux tests précoces du nouveau mode de stockage des commandes proposé par WooCommerce, qui vise à terme à remplacer le stockage des commandes sous forme d’articles classiques par des tables dédiées, plus performantes à grande échelle. Ce mode restait, en septembre 2022, une piste de travail en cours d’évaluation par l’équipe WooCommerce, activable uniquement en environnement de test, jamais recommandée en production à ce stade.
L’extension tierce de gestion des stocks, elle, continuait d’écrire le statut de commande directement via update_post_meta(), en ciblant l’ancien format de stockage basé sur le type de contenu shop_order. Le template du Site Editor, construit pour lire cette donnée via le même mécanisme classique, affichait donc une valeur non synchronisée avec la donnée réelle, désormais partiellement gérée par le nouveau mode de stockage en cours de test.
Correctif : passer par les fonctions d’abstraction WooCommerce
La correction retenue a consisté à ne plus jamais lire directement une métadonnée de commande via get_post_meta() dans le template ou dans les blocs personnalisés du thème, mais à systématiquement passer par les méthodes d’abstraction fournies par l’objet WC_Order, conçues justement pour rester compatibles quel que soit le mode de stockage actif.
// À éviter, dépendant du format de stockage
$statut = get_post_meta( $commande_id, '_order_status', true );
// Compatible quel que soit le mode de stockage actif
$commande = wc_get_order( $commande_id );
$statut = $commande->get_status();
La même règle s’applique à l’extension tierce responsable du décalage initial : son développeur a été contacté, avec la recommandation explicite de remplacer ses appels directs à update_post_meta() par la méthode update_meta_data() de l’objet commande, suivie d’un appel à save(), seule façon de garantir une écriture cohérente quel que soit le mode de stockage choisi par la boutique.
Prévention : ne jamais lire un post meta de commande directement
Cette règle simple, ne jamais accéder directement aux métadonnées d’une commande WooCommerce par les fonctions génériques de WordPress, mais toujours par l’objet WC_Order et ses méthodes dédiées, doit devenir systématique dès la conception d’un template ou d’un bloc personnalisé, bien avant qu’une bascule de mode de stockage ne soit seulement envisagée sur une boutique.
- Auditer chaque template et bloc personnalisé du thème à la recherche d’appels directs à
get_post_meta()ouupdate_post_meta()sur des commandes. - Remplacer systématiquement ces appels par les méthodes de l’objet
WC_Order. - Signaler aux développeurs d’extensions tierces actives sur la boutique les mêmes recommandations.
Sur ce genre de projet, la bonne pratique la plus rentable reste la plus ennuyeuse à documenter : ne jamais toucher directement une métadonnée de commande, même quand cela fonctionne très bien depuis des années sur l’ancien format.
Ce que ce billet ne couvre pas
Ce billet ne traite ni la migration complète d’un catalogue d’extensions tierces vers le nouveau mode de stockage, sujet propre à chaque extension concernée, ni la configuration détaillée de ce mode de stockage lui-même, encore en évolution active à cette date et documentée séparément par l’équipe WooCommerce.
En résumé
Un template du Site Editor qui affiche un statut de commande incorrect, dans un contexte de test du nouveau mode de stockage à haute performance de WooCommerce, révèle presque toujours un accès direct aux métadonnées plutôt qu’un passage par l’objet WC_Order. Corriger cette habitude, avant même toute bascule généralisée, évite bien des décalages silencieux et difficiles à diagnostiquer.
