# Compatibilité HPOS d’un thème WooCommerce : ce qu’il faut vérifier

> Le stockage des commandes en tables dédiées a rendu obsolètes certaines habitudes de templates surchargés. Passage en revue d'un thème enfant Storefront ancien avant migration.

- Auteur : Clément Hadrot
- Publié le : 2026-02-16
- Mis à jour le : 2026-02-16
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/compatibilite-hpos-theme-woocommerce/

## L’essentiel

- HPOS change la structure de stockage, pas l'API publique
- Les requêtes directes à wp_posts sur les commandes sont le vrai risque
- Les templates de compte et commande méritent un audit ciblé

Un client exploite depuis des années une boutique construite sur un thème enfant de Storefront, largement personnalisé au niveau des templates de compte client et de détail de commande. Avant d'activer HPOS (High-Performance Order Storage), le stockage des commandes en tables dédiées désormais recommandé par défaut sur les installations récentes de WooCommerce, un audit ciblé du thème enfant s'imposait, faute de documentation existante sur ce qui avait été surchargé au fil du temps.

HPOS ne change rien à l'API publique de WooCommerce que les développeurs de thèmes sont censés utiliser : les fonctions comme `wc_get_order()` ou les hooks standards continuent de fonctionner à l'identique. Le risque réel se situe dans les templates ou fonctions qui contournaient cette API pour accéder directement aux données de commande stockées comme des articles ordinaires dans `wp_posts`.

## Ce que HPOS change concrètement

Avant HPOS, chaque commande WooCommerce était enregistrée comme un article personnalisé du type `shop_order`, avec ses métadonnées stockées dans `wp_postmeta`, exactement comme un article de blog classique. Avec HPOS activé, les commandes sont stockées dans des tables dédiées, structurées spécifiquement pour ce besoin, plus performantes à grande échelle mais incompatibles avec toute requête qui présupposerait l'ancienne structure `wp_posts`.

## L'audit du thème enfant, poste par poste

> L'essentiel à retenir : HPOS change la structure de stockage, pas l'API publique ; Les requêtes directes à wp_posts sur les commandes sont le vrai risque ; Les templates de compte et commande méritent un audit ciblé

Nous avons passé en revue systématiquement, dans cet ordre, chaque fichier du thème enfant susceptible de manipuler des données de commande :

1. Les templates surchargés du dossier `woocommerce/myaccount/`, notamment `orders.php` et `view-order.php`, vérifiés pour s'assurer qu'ils utilisent bien `wc_get_orders()` plutôt qu'une requête `WP_Query` directe sur le type de post `shop_order`.
2. Les fonctions personnalisées du `functions.php` du thème enfant qui accédaient aux métadonnées de commande via `get_post_meta()` au lieu de `$order->get_meta()`, une pratique à corriger impérativement avant activation de HPOS.
3. Toute requête SQL directe via `$wpdb` ciblant explicitement la table `wp_posts` avec un filtre sur le type de post `shop_order`, un motif que nous avons effectivement trouvé une fois dans une fonction de reporting personnalisée ajoutée par un ancien prestataire.
4. Les widgets ou blocs personnalisés du thème affichant un résumé de commande en page d'accueil du compte, souvent oubliés lors des audits centrés uniquement sur les templates principaux.

## Le cas trouvé : une fonction de reporting incompatible

La fonction de reporting personnalisée découverte lors de l'audit interrogeait directement `wp_posts` pour compter les commandes par statut, sans passer par l'API WooCommerce :

```
// Ancien code incompatible HPOS
global $wpdb;
$total = $wpdb->get_var(
    "SELECT COUNT(*) FROM {$wpdb->posts}
     WHERE post_type = 'shop_order' AND post_status = 'wc-completed'"
);
```

Cette requête aurait silencieusement retourné zéro résultat une fois HPOS actif, les commandes n'étant plus stockées dans `wp_posts`. La correction consiste à utiliser l'API de requête officielle de WooCommerce, compatible avec les deux modes de stockage :

```
$total = wc_get_orders( array(
    'status' => 'completed',
    'return' => 'ids',
    'limit'  => -1,
) );
$total = count( $total );
```

## Le mode de compatibilité, un filet de sécurité temporaire

WooCommerce propose un mode de synchronisation qui maintient les deux structures de stockage en parallèle pendant une période de transition, ce qui a permis de vérifier le comportement du thème enfant corrigé en conditions réelles avant de désactiver définitivement l'ancien stockage. Ce filet de sécurité ne dispense toutefois pas de l'audit préalable : il retarde la découverte d'un problème, il ne l'empêche pas.

> Le mode de compatibilité HPOS est un bon filet, pas une excuse pour sauter l'audit. Une incompatibilité non corrigée refera surface le jour où l'ancien stockage sera définitivement désactivé.

## Vérifications complémentaires côté plugins tiers

Au-delà du thème enfant lui-même, l'audit a également porté sur les extensions installées qui interagissent avec les commandes (export comptable, module de fidélité), chacune vérifiée pour sa déclaration officielle de compatibilité HPOS auprès de son éditeur, information généralement disponible dans la documentation ou le changelog de l'extension concernée.

## En résumé

Un thème enfant WooCommerce ancien peut cacher des accès directs à la structure de données des commandes, invisibles tant que l'ancien mode de stockage reste actif. L'audit avant activation de HPOS doit cibler spécifiquement les templates de compte et de commande, ainsi que toute fonction personnalisée manipulant des métadonnées de commande, en vérifiant systématiquement le recours à l'API officielle de WooCommerce plutôt qu'à des requêtes directes sur `wp_posts`.