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
);
}
} );

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_Queryciblantpost_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.