# Polylang et le HPOS : des commandes traduites introuvables dans l’administration

> Sur une boutique multilingue, certaines commandes disparaissent de la liste après le passage au stockage haute performance. Le lien langue-commande est en cause.

- Auteur : WordPress Développement
- Publié le : 2023-12-01
- Mis à jour le : 2023-12-01
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/polylang-hpos-commandes-traduites-introuvables/

## L’essentiel

- Polylang associe la langue à une commande via une table de traduction pensée pour wp_posts
- Le HPOS déplace les commandes hors de wp_posts, cassant cette association
- La correction passe par le hook de synchronisation de langue propre au nouveau schéma

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

> L'essentiel à retenir : Polylang associe la langue à une commande via une table de traduction pensée pour wp_posts ; Le HPOS déplace les commandes hors de wp_posts, cassant cette association ; La correction passe par le hook de synchronisation de langue propre au nouveau schéma

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_id` qui 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.