Pourquoi les commandes passées en espagnol n’apparaissaient-elles plus dans la liste des commandes de l’administration, alors qu’elles existaient bien en base et que le client avait bien reçu son e-mail de confirmation ? C’est la question posée sur une boutique vendant en français, anglais et espagnol via Polylang, peu après l’activation du stockage de commandes haute performance (HPOS).
Avant la bascule, l’administration filtrait les commandes par langue exactement comme elle filtre les articles de blog, via le sélecteur de langue Polylang en haut de l’écran. Après la bascule, ce filtre continuait d’afficher les commandes françaises et anglaises, mais renvoyait une liste vide pour l’espagnol, sans erreur visible.
Le mécanisme Polylang, pensé pour wp_posts
Polylang associe une langue à un contenu via la table wp_term_relationships, en s’appuyant sur une taxonomie interne (language) rattachée à l’identifiant de post. Ce mécanisme fonctionne nativement pour tout type de contenu basé sur wp_posts — articles, pages, et historiquement les commandes WooCommerce, stockées avant le HPOS comme un type de post particulier (shop_order).
Le HPOS déplace les commandes vers des tables dédiées (wp_wc_orders et consorts), en dehors de wp_posts. Une commande HPOS n’a donc plus, par défaut, de relation de taxonomie avec wp_term_relationships de la même façon qu’un article de blog : l’association de langue posée par Polylang au moment de la commande devenait orpheline, rattachée à un identifiant qui n’existait plus dans le nouveau schéma de la même façon.
Pourquoi une langue fonctionnait et pas les autres
Le détail qui a permis de cerner le problème : le français, langue par défaut du site, fonctionnait normalement car le filtre par langue de l’administration WooCommerce traitait l’absence de langue explicite comme un rattachement implicite à la langue par défaut. L’anglais, activé depuis plus longtemps que l’espagnol, bénéficiait d’une synchronisation ajoutée dans une version antérieure du plugin de compatibilité Polylang-WooCommerce. L’espagnol, activé après la bascule HPOS, n’avait jamais eu cette synchronisation posée du tout.
La correction : synchroniser via le hook propre au HPOS
La solution ne consiste pas à forcer une relation de taxonomie classique sur un identifiant qui n’est plus un post_id, mais à s’appuyer sur le hook de sauvegarde de commande compatible HPOS pour stocker la langue directement en meta de commande, puis à adapter la requête de filtrage de l’administration en conséquence :
add_action( 'woocommerce_checkout_update_order_meta', function( $order_id ) {
$order = wc_get_order( $order_id );
$order->update_meta_data( '_order_language', pll_current_language() );
$order->save();
} );
add_filter( 'woocommerce_order_list_table_prepare_items_query_args', function( $args ) {
if ( ! empty( $_GET['lang'] ) ) {
$args['meta_query'][] = array(
'key' => '_order_language',
'value' => sanitize_text_field( $_GET['lang'] ),
);
}
return $args;
} );Cette approche stocke la langue comme une donnée de commande à part entière, via l’API WC_Order, plutôt que de dépendre d’une relation de taxonomie héritée d’un modèle de données que le HPOS ne suit plus de la même manière. Un script de rattrapage ponctuel a ensuite parcouru les commandes existantes pour renseigner cette meta à partir de la relation de taxonomie encore présente sur les commandes non migrées.
Vérifications à mener après ce type de correctif
- Confirmer que chaque nouvelle commande, quelle que soit la langue, porte bien la meta
_order_language. - Vérifier le filtre par langue sur l’écran de liste des commandes pour chacune des langues actives.
- Contrôler que les e-mails automatiques WooCommerce (confirmation, expédition) restent envoyés dans la bonne langue, une dépendance distincte de l’affichage administrateur.
Conseil maison : tout mécanisme d’extension qui repose sur une relation de taxonomie WordPress classique doit être réévalué avant d’activer le HPOS, car cette relation suppose implicitement un
post_idqui n’existe plus pour les commandes dans le nouveau schéma.
En résumé
Le lien entre Polylang et les commandes WooCommerce, initialement construit sur le modèle générique des articles WordPress, ne survit pas tel quel au passage au HPOS. Stocker la langue directement comme meta de commande, via l’API native WC_Order, restaure un filtrage fiable en administration. La procédure de migration HPOS elle-même, avec ses étapes de synchronisation des commandes existantes, reste un sujet à part entière non couvert ici.
