J'ai été dans l'appel quand une boutique a activé le stockage de commande haute performance et j'ai regardé un plugin d'expédition se taire, une synchronisation CRM revenir vide et un plugin de chat continuer à répondre à partir de données qu'il ne pouvait plus lire. À ce stade ce motif est familier à tous ceux qui exécutent WooCommerce à l'échelle.
Le plugin de chat sur votre boutique n'a probablement pas été le bruyant. La plupart des outils de chat ne lisent pas les données de commande du tout, donc HPOS ne les plante pas. Mais ceux qui lisent les commandes, pour le contexte d'escalade, le suivi des commandes ou le chat post-achat, échouent silencieusement. Le chat continue à répondre, juste à partir des mauvaises données.
Cet article est pour les propriétaires de boutiques qui exécutent WooCommerce 8.0 ou ultérieur, évaluent les outils de chat et veulent savoir si HPOS va déclencher l'intégration. C'est aussi pour les propriétaires de boutiques qui ont déjà un outil de chat et veulent confirmer qu'il a survécu à la migration.
Ce que HPOS a changé
Les commandes WooCommerce habitaient la même table wp_posts que les produits, les pages et les articles, avec les métadonnées de commande dans wp_postmeta. Stocker les données transactionnelles de haut volume dans les tables de contenu de WordPress était toujours un contournement. Les requêtes de commandes étaient lentes, les index n'étaient pas construits pour les modèles de lecture transactionnels et la rapportage sur une boutique occupée pouvait prendre des secondes.
HPOS a introduit de nouvelles tables : wc_orders, wc_order_addresses, wc_order_operational_data et wc_orders_meta. Les données de commande y vivent maintenant. Les requêtes sont indexées pour les modèles d'accès que les commandes ont. Le gain de performance est significatif sur les boutiques faisant du volume de commandes significatif.
WooCommerce supporte trois modes :
- Postes uniquement. Le stockage hérité ; les commandes vivent dans
wp_posts. Les nouvelles boutiques ne font plus défaut ici. - HPOS uniquement. Les commandes vivent dans les tables personnalisées ;
wp_postsn'est pas utilisé pour les commandes. Par défaut pour les nouvelles boutiques à partir de WooCommerce 8.2 et ultérieurs. - HPOS avec synchronisation aux postes. Les deux dispositions sont tenues synchronisées. C'est le mode de migration pour les boutiques se déplaçant de postes à HPOS sans casser immédiatement les plugins plus anciens.
Le défi pour les plugins de chat : quand une boutique bascule de postes uniquement à HPOS uniquement, le plugin doit interroger les nouvelles tables. S'il interroge toujours wp_posts et wp_postmeta pour les commandes, il obtient zéro résultats.
Où les plugins de chat touchent les données de commande
La plupart des plugins de chat ne touchent pas du tout les données de commande. Synchronisation de produit, synchronisation de page, routage de conversation : aucun de ceux-ci n'a besoin de commandes. Si votre plugin de chat est en lecture seule sur le catalogue, HPOS ne lui importe pas.
Mais quatre caractéristiques de chat touchent les commandes :
- Suivi des commandes dans le chat. L'acheteur demande « où est ma commande #12345 » et le chat cherche le statut de la commande. C'est une lecture directe contre les tables de commandes.
- Contexte de chat post-achat. Le chat détecte un client revenant qui a récemment acheté, référence la commande, demande comment cela s'est déroulé. Nécessite de lire les commandes récentes du client.
- Contexte d'escalade aux agents en direct. Quand le chat escalade à un humain, il présente l'historique des commandes du client afin que l'agent ne demande plus. Le client déteste être demandé.
- Suivi de conversion et attribution. Le chat suit session de chat → panier → achat. L'événement « achat » est lu de la commande. Si le chat ne peut pas voir les commandes, le tableau de bord montre zéro revenus attribués, même si le chat ferme des ventes.
Le dernier est l'échec silencieux le plus dommageable. Le chat fonctionne. Les acheteurs achètent. Le tableau de bord dit « 0 $ attribués ». Le propriétaire de la boutique conclut que le chat ne vaut pas les dépenses et annule.
Les trois modes d'échec HPOS
1. Requêtes wp_posts codées en dur
Les plugins de chat plus anciens ont été écrits quand wp_posts était le seul endroit où les commandes vivaient. Le code lit WP_Query avec post_type='shop_order'. En mode HPOS uniquement, cette requête ne retourne rien.
Si la dernière version de votre plugin était antérieure à WooCommerce 8.2 (décembre 2023), supposez que c'est le cas jusqu'à preuve du contraire. J'ai audité les plugins publiés après cette date qui interrogent toujours wp_posts directement parce que le chemin du code de commande était copié-collé depuis une base de code plus ancienne.
2. Déclaration de compatibilité manquante
WooCommerce exige que les plugins qui touchent les commandes déclarent la compatibilité HPOS :
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
);
}
});
Sans cette déclaration, WooCommerce signale le plugin comme incompatible dans l'admin et, selon votre version, la boutique peut refuser d'activer HPOS du tout. Le plugin de chat continue de bloquer la migration HPOS de votre boutique jusqu'à ce que vous le supprimiez ou le remplaciez.
3. Le mauvais mode de CRUD
Même quand un plugin interroge les bonnes tables, il pourrait écrire les métadonnées de commande en utilisant update_post_meta() au lieu de l'API de commande CRUD ($order->update_meta_data() + $order->save()). Sur une configuration posts+HPOS-sync, cela peut écrire à un côté sans l'autre synchronisation. Les données de commande dérivent. Les rapports cessent de correspondre.
Les plugins de chat faisant l'escalade stockent souvent le contexte de conversation comme métadonnées de commande. S'ils utilisent l'ancien motif CRUD, les métadonnées vivent dans wp_postmeta, mais sur les boutiques HPOS uniquement wp_postmeta n'est pas lu pour les commandes, donc les métadonnées deviennent des données orphelines.
Comment Emporiqa gère HPOS
Le plugin Emporiqa déclare la compatibilité HPOS à chaque version. Le plugin est en lecture seule contre les commandes pour deux objectifs : recherches de suivi de commande (quand configuré) et attribution de conversion (session de chat à achat).
Pour le suivi des commandes, le plugin utilise wc_get_order($order_id) plutôt que les requêtes directes de table. La couche CRUD de WooCommerce achemine la lecture vers la bonne table en fonction du mode de stockage actif, donc le même code fonctionne sur les boutiques postes uniquement, HPOS uniquement et HPOS-avec-sync.
Pour l'attribution de conversion, le plugin écoute le hook woocommerce_order_status_changed qui s'exécute quel que soit le mode de stockage. L'ID de session de chat est associé aux données d'attribution du client de la commande. Si le chat a fermé la vente, la commande est attribuée dans le tableau de bord en quelques secondes après la complétion de la commande.
Si votre boutique doit attacher des données personnalisées aux commandes pour le contexte du chat, exposez-la via le CRUD de commande :
add_action('emporiqa_handoff_initiated', function($conversation_id, $order_id) {
if ($order_id) {
$order = wc_get_order($order_id);
$order->update_meta_data('_emporiqa_handoff_id', $conversation_id);
$order->save();
}
}, 10, 2);
Ce code fonctionne si votre boutique est en postes uniquement ou HPOS uniquement.
Comment tester la compatibilité HPOS d'un plugin de chat
Trois vérifications. Aucun ne prend plus d'une minute.
- Vérifiez la liste de compatibilité de l'admin WooCommerce. Naviguez vers WooCommerce → Paramètres → Avancé → Caractéristiques. La ligne « High-Performance order storage » affiche les plugins compatibles et incompatibles. Si votre plugin de chat est dans la liste incompatible, arrêtez ici. Le plugin est cassé sur HPOS jusqu'à ce que le fournisseur le corrige.
- Placez une commande de test sur une copie de staging. Tournez une copie de staging de votre boutique avec HPOS activé. Placez une commande de test. Vérifiez le tableau de bord du chat. Si l'outil de chat suit l'attribution, la commande devrait y apparaître en une minute.
- Déclenchez une escalade et vérifiez le contexte de la commande. Si le plugin de chat affiche l'historique des commandes pendant l'escalade, commencez un chat en tant que client de test connecté avec une commande antérieure, déclenchez l'escalade, confirmez que l'agent voit la commande dans le contexte de l'escalade. S'il montre vierge, le plugin lit les commandes de la manière hérité.
Si les trois réussissent, le plugin est HPOS-sûr pour les caractéristiques qui importent à la plupart des boutiques.
Ce que cela ne fait pas
- Migrer les données de commande de votre plugin de chat existant. Si vous basculez à partir d'un plugin de chat non conscient de HPOS et que ce plugin a stocké le contexte de conversation dans
wp_postmeta, ces données n'apparaîtront pas magiquement danswc_orders_meta. Vous perdrez le contexte de chat historique attaché aux vieilles commandes. Ceci est un coût unique de la migration. - Forcer HPOS sur les boutiques qui ne le supportent pas. WooCommerce supporte HPOS à partir de la version 8.0. Les boutiques sur des versions antérieures ne peuvent pas l'activer. Le plugin fonctionne sur l'un ou l'autre mode.
- Bloquer la migration. Certains plugins refusent de charger jusqu'à ce que la boutique bascule au mode postes. Emporiqa charge sur l'un ou l'autre mode et s'exécute de la même façon sur l'un ou l'autre.
Pourquoi la compatibilité HPOS est un signal d'achat
La maintenance de plugin est un travail peu attrayant. Les fournisseurs qui ont livré la compatibilité HPOS, déclarée correctement et mis à jour leurs chemins de code de commande ont démontré qu'ils suivent le noyau de WooCommerce. Les fournisseurs qui ne l'ont pas fait, après deux ans de disponibilité de HPOS, ne suivent probablement rien d'autre non plus.
Avant de signer un an de frais mensuels sur n'importe quel plugin de chat pour une boutique WooCommerce avec du volume de commande significatif, vérifiez la colonne HPOS. C'est un moyen bon marché de filtrer les plugins qui seront toujours entretenus l'année prochaine parmi ceux qui fonctionnent sur pilote automatique.
Lecture connexe sur WooCommerce + chat : produits variables, multilingue WPML et Polylang et survie du trafic de pointe. Pour la présentation complète de la configuration WooCommerce, voir pourquoi la plupart des plugins de chat WooCommerce arrivent mal l'architecture. Pour mettre des chiffres sur l'impact en aval du plugin de chat, le guide de suivi de conversion couvre le côté de l'attribution.
Essayez la démo en direct à demo.emporiqa.com ou installez le plugin sur une boutique bac à sable avec HPOS activé et exécutez le test des trois vérifications ci-dessus. Les étapes de configuration et les notes complètes HPOS sont dans la documentation WooCommerce.