# WooCommerce 8.x : ce que le HPOS par défaut change pour vos extensions

> Le stockage des commandes en tables dédiées devient le comportement par défaut de WooCommerce 8.x. Ce que cela change concrètement pour des extensions maison déjà en production.

- Auteur : Clément Hadrot
- Publié le : 2024-12-11
- Mis à jour le : 2024-12-11
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/woocommerce-8-hpos-defaut-extensions/

## L’essentiel

- Les nouvelles installations démarrent directement en HPOS
- Les requêtes SQL directes sur wp_posts cessent de fonctionner
- La compatibilité se déclare explicitement via une constante

Le HPOS (High-Performance Order Storage), ce système de tables dédiées aux commandes introduit en alternative au stockage historique dans `wp_posts`, franchit une nouvelle étape avec WooCommerce 8.x : il devient le comportement par défaut sur toute nouvelle installation. Pour une boutique existante déjà migrée, rien ne change du jour au lendemain. Pour une extension maison qui n'a jamais été auditée sous cet angle, en revanche, cette bascule par défaut change la donne dès le premier client qui installe une boutique neuve avec cette extension.

Cet article ne couvre pas la procédure de migration initiale d'une boutique existante vers le HPOS, déjà détaillée par ailleurs, mais se concentre sur l'impact concret pour du code d'extension déjà écrit, en particulier tout ce qui contournait l'API WooCommerce pour accéder directement aux données de commande.

## Ce qui casse en premier : les requêtes SQL directes

Le cas le plus fréquent rencontré en audit : une requête SQL construite à la main, interrogeant directement `wp_posts` et `wp_postmeta` pour extraire des statistiques de commande, par exemple pour un tableau de bord personnalisé de chiffre d'affaires. Ce genre de requête, autrefois parfaitement fonctionnelle, ne retourne simplement plus rien de cohérent une fois les commandes stockées dans les tables dédiées `wp_wc_orders` et `wp_wc_order_operational_data`.

```
// A éviter depuis longtemps, incompatible HPOS
$wpdb->get_results( "
    SELECT ID, post_date FROM {$wpdb->posts}
    WHERE post_type = 'shop_order' AND post_status = 'wc-completed'
" );

// Compatible HPOS et pré-HPOS
$commandes = wc_get_orders( array(
    'status' => 'completed',
    'limit'  => -1,
    'return' => 'ids',
) );
```

## Déclarer la compatibilité, une étape qui reste manuelle

Une extension n'est jamais automatiquement considérée comme compatible : elle doit le déclarer explicitement, dès son chargement, via `FeaturesUtil::declare_compatibility()`. Sans cette déclaration, WooCommerce continue de fonctionner mais affiche un avertissement dans l'administration, et surtout ne garantit aucune compatibilité testée de l'extension avec le nouveau mode de stockage.

```
add_action( 'before_woocommerce_init', function() {
    if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
        \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
            'custom_order_tables',
            __FILE__,
            true
        );
    }
} );
```

> L'essentiel à retenir : Les nouvelles installations démarrent directement en HPOS ; Les requêtes SQL directes sur wp_posts cessent de fonctionner ; La compatibilité se déclare explicitement via une constante

## Détecter dynamiquement le mode actif

Une extension qui doit s'adapter selon le mode de stockage actif peut interroger la classe utilitaire dédiée plutôt que de supposer un mode fixe. Ce test est utile en particulier pour du code de transition, maintenu pendant la période où coexistent encore des boutiques en HPOS et d'autres en stockage classique.

```
use Automattic\WooCommerce\Utilities\OrderUtil;

if ( OrderUtil::custom_orders_table_usage_is_enabled() ) {
    // logique spécifique au stockage HPOS
} else {
    // logique de repli sur l'ancien stockage
}
```

### Les métadonnées de commande restent accessibles de la même façon

Bonne nouvelle pour beaucoup d'extensions : l'API de métadonnées standard, `$order->get_meta()`, `$order->update_meta_data()` et `$order->save()`, reste inchangée quel que soit le mode de stockage actif. Le HPOS ne demande donc pas de réécrire tout le code qui manipule des commandes via les objets `WC_Order`, seulement celui qui contournait ces objets par des requêtes directes.

## Autres changements à surveiller

- Les hooks liés au cycle de vie WordPress classique des posts (`save_post`, `before_delete_post`) ne se déclenchent plus pour les commandes en HPOS
- Les requêtes `WP_Query` ciblant `post_type => 'shop_order'` ne retournent plus rien en mode HPOS
- La synchronisation bidirectionnelle, activable temporairement, permet une période de transition mais n'est pas destinée à rester active indéfiniment

> Le HPOS ne demande pas de réécrire toute extension WooCommerce, seulement d'auditer précisément les endroits où le code a contourné l'API officielle pour aller plus vite. Ce sont toujours ces raccourcis-là qui reviennent facturer leur dette technique en premier.

## Notre verdict

Le passage du HPOS en comportement par défaut n'est pas une surprise pour qui suit le sujet depuis son introduction, mais il déplace le risque : ce n'est plus seulement une migration à planifier sur les boutiques existantes, c'est aussi un test de compatibilité à refaire sur chaque extension maison avant de la proposer telle quelle sur une nouvelle installation.