Synchronisation HPOS WooCommerce bloquée : vérifier les commandes en attente

Identifier le stockage qui fait foi

WooCommerce indique que des commandes restent à synchroniser. Le choix du stockage haute performance, appelé HPOS, reste indisponible ou le compteur ne baisse plus. Avant de relancer un traitement, ouvrez WooCommerce > Réglages > Avancé > Fonctionnalités. Dans la zone de stockage des commandes, relevez le choix actif, l’état du mode de compatibilité et le nombre d’éléments en attente lorsqu’il est affiché. Faites une capture datée dans un espace privé. Une mention d’extension incompatible demande d’abord de traiter cette dépendance. Ici, vous cherchez pourquoi les données qui doivent être copiées ne se rapprochent plus.

Le stockage actif fait foi. Lorsque le stockage historique des articles WordPress est sélectionné, la synchronisation prépare les tables de commandes HPOS. Lorsque HPOS est actif, la synchronisation peut mettre à jour la copie historique. Le même compteur peut donc correspondre à deux sens différents. Avant tout essai, notez la source et la destination. Si les fonctionnalités affichent une bascule automatique une fois la synchronisation terminée, notez son état dès ce relevé. Une option active peut changer le stockage de référence sans nouvelle sélection manuelle. Une table qui contient des lignes récentes ne remplace pas ce contrôle. Selon le stockage et le mode actifs, certaines écritures ou lignes intermédiaires peuvent exister dans les deux ensembles.

Préparez une sauvegarde exploitable de la base et une copie récente si une intervention doit écrire des données. Sur une boutique ouverte, notez quelles commandes et quels remboursements peuvent arriver après la sauvegarde. Le rétablissement d’une base entière pourrait écarter ces écritures. Pour les essais, neutralisez les paiements, courriels et webhooks de la copie. Vous aurez besoin d’un compte autorisé à consulter WooCommerce. Les commandes de terminal demandent aussi un accès SSH et une installation WP-CLI qui peut charger la bonne version de WooCommerce.

Comparer la progression à deux moments

Relevez le compteur au premier passage. Attendez un intervalle adapté à la cadence de la file et regardez si des actions se terminent entre les deux relevés. Évitez de recharger en boucle un écran lourd sur une boutique active. Une baisse du nombre en attente et des actions terminées qui progressent sont de bons indices. Un nombre stable peut signaler une interruption, mais aussi des nouvelles commandes pendant que les anciennes sont traitées. Comparez l’heure des actions et le volume récent avant de conclure.

L’exemple suivant est fictif. Une copie qui passe de 800 à 400 éléments et dont les actions terminées se succèdent est en train de traiter sa file. Sur une autre copie, le compteur reste à 800 et la même tâche échoue à chaque tentative avec une erreur de base. La priorité est alors d’identifier cette erreur. Si le compteur tombe à zéro mais qu’un contrôle révèle des différences sur une commande, vérifiez les données avant d’envisager un changement de stockage. Le nombre en attente et la comparaison des données répondent à deux questions différentes.

1. Dans Fonctionnalités, relevez le stockage actif, le mode de compatibilité, l’heure et le compteur.
2. Comparez avec un second relevé après un intervalle où le planificateur a eu l’occasion de travailler.
3. Notez aussi les commandes récentes et les actions terminées. Si le compteur stagne et que les tâches n’avancent plus, ouvrez le journal des actions planifiées.

Approche 1. Lire les actions planifiées et leurs journaux

Dans WooCommerce > État > Actions planifiées, utilisez les filtres d’état et la recherche. Selon l’installation, l’écran peut aussi être accessible dans Outils > Actions planifiées. Relevez le nom de l’action, parfois appelé hook, l’heure prévue et son journal. La documentation de WooCommerce décrit notamment la détection puis le traitement de lots par wc_schedule_pending_batch_process et wc_run_batch_process. Les noms utilisés peuvent évoluer avec la version. Dans le code actuel de WooCommerce, le mode de traitement en arrière-plan par intervalle utilise aussi woocommerce_custom_orders_table_background_sync. Une action de lot peut servir à plusieurs types de traitements. Vérifiez son contexte et ses arguments avant de l’attribuer à HPOS.

Les états éclairent des situations différentes. Une action en attente à une heure future peut être normale. Des actions en attente longtemps après leur échéance, avec d’autres tâches WooCommerce également en retard, orientent vers le déclenchement du planificateur. Une action en cours appelle une vérification de son activité avant toute nouvelle exécution. Une action en échec demande la lecture de son journal et, au besoin, du journal PHP ou de la base au même moment. Gardez la distinction entre le déclenchement de la tâche et l’opération qu’elle essaie d’effectuer.

1. Ouvrez l’écran des actions planifiées et cherchez les tâches liées au traitement de commandes.
2. Consultez les vues En attente, En cours, Terminées et Échouées autour du dernier relevé. Lisez le journal d’une action précise.
3. Si plusieurs types de tâches ne se lancent plus, vérifiez le planificateur de l’installation avant de modifier le stockage.
4. Si une tâche se lance mais échoue, consignez son identifiant et la première erreur avant de décider du prochain essai.

Traiter une action échouée sans relancer toute la file

Si le journal nomme une erreur PHP, un manque de ressources ou un échec d’écriture dans la base, relevez le premier message complet et son heure. Une longue suite de tentatives peut répéter la même conséquence. Sur la copie, cherchez la commande ou le groupe touché sans reproduire des effets externes. Si le journal désigne toujours le même composant, vérifiez sa compatibilité et sa version. Si les échecs concernent des tâches de types différents, rapprochez-les d’un changement de planificateur, de PHP ou de ressources plutôt que du stockage seul.

Avant une reprise manuelle, vérifiez que la tâche précédente a effectivement cessé. Une action marquée en cours mérite un contrôle du traitement correspondant. Lancer une autre copie du travail pendant que la première écrit peut rendre le résultat difficile à interpréter. Si le planificateur utilise des tâches externes, des requêtes asynchrones ou des commandes WP-CLI, faites identifier les mécanismes réellement présents sur la copie. Arrêter un seul mécanisme ne garantit pas l’arrêt des autres.

Une fois la cause corrigée, gardez le stockage de référence et observez la reprise normale. Le premier résultat utile est une action terminée sans la même erreur, accompagnée d’une évolution cohérente du compteur. Si le même événement échoue de nouveau, arrêtez les relances manuelles et conservez le journal. Une action en échec peut permettre de retrouver un identifiant ou une cause sans exposer de données client dans le relevé transmis.

1. Identifiez l’erreur récurrente et corrigez sa cause sur la copie.
2. Vérifiez qu’un seul mécanisme est chargé de reprendre la synchronisation pour l’essai.
3. Comparez le journal et le compteur avant et après. En cas d’échec identique, conservez la preuve et rétablissez les réglages de test.

Approche 2. Mesurer la synchronisation en WP-CLI

Avec un accès SSH et une copie identifiée, WP-CLI permet de relever le stockage actif et le compteur sans passer par l’interface. Les commandes ci-dessous utilisent le groupe wc hpos documenté par WooCommerce. Vérifiez qu’il est proposé par la version installée. Si la commande n’existe pas, lisez l’aide de cette version ou revenez à l’écran des fonctionnalités. Une commande absente ne signale pas une commande WooCommerce manquante dans la base.

Remplacez le chemin et l’adresse fictifs par ceux de la copie. En multisite, indiquez l’adresse du sous-site qui possède la boutique. Vérifiez l’installation et le site sélectionnés avant de lire les résultats. La commande status indique notamment si HPOS et le mode de compatibilité sont actifs. count_unmigrated affiche le nombre d’éléments en attente. Ces deux commandes fournissent un diagnostic. Le compteur ne vérifie pas à lui seul chaque champ des deux stockages.

1. Relevez l’état sur la copie et comparez-le à la capture du panneau WooCommerce.
2. Notez le compteur et l’heure. Répétez la lecture après une période de traitement normale.
3. Si le compteur est stable, comparez ce résultat à l’activité de la file et à la dernière erreur relevée.

racine='/chemin/vers/la-copie'
site='https://copie.exemple.invalid'
wp --path="$racine" --url="$site" wc hpos status
wp --path="$racine" --url="$site" wc hpos count_unmigrated

Utiliser la synchronisation manuelle avec un seul opérateur

La commande wc hpos sync lance des écritures. D’après WooCommerce, elle applique les changements dans le sens déterminé par le stockage actuellement sélectionné. Avant de l’employer, contrôlez ce sens, la sauvegarde et l’état du mode de compatibilité. Sur une copie, désactivez la bascule automatique si cette option existe et si votre objectif est de mesurer la synchronisation en conservant le stockage actif. Une bascule déclenchée dès que le compteur atteint zéro pourrait modifier le sens des essais suivants.

N’utilisez cette commande que si le responsable de la copie a préparé un essai avec un seul mécanisme de synchronisation actif. Il doit pouvoir empêcher que les traitements automatiques de la copie et la commande de terminal écrivent simultanément. Gardez le site de service hors du périmètre de cet exemple. Sur une grande boutique, préparez séparément le créneau, les ressources et la procédure d’arrêt avec l’exploitant. Pendant l’essai, relevez les mécanismes suspendus et la valeur initiale de la bascule automatique. Après l’arrêt confirmé de la commande et les contrôles, rétablissez seulement les mécanismes et réglages autorisés pour la copie. Si un traitement reste en cours, attendez de pouvoir l’attribuer avant de réactiver un autre lanceur.

1. Confirmez la source et la destination dans WooCommerce, puis contrôlez la copie et son point de restauration.
2. Lancez une seule synchronisation manuelle dans ce périmètre. Conservez son résultat et la première erreur éventuelle.
3. Relisez le compteur et le journal. Si la commande échoue, gardez le stockage de référence et déterminez quelles écritures ont déjà été appliquées avant de choisir une reprise.

wp --path='/chemin/vers/la-copie' --url='https://copie.exemple.invalid' wc hpos sync

Vérifier les écarts et les commandes témoins

Un compteur à zéro indique que le synchroniseur ne voit plus de travail en attente. Il ne suffit pas à établir que tous les champs utiles concordent, en particulier si une intégration a écrit en dehors des mécanismes de WooCommerce. Sur une copie où le mode de compatibilité est actif et où les deux stockages sont censés correspondre, la commande wc hpos verify_data compare leurs données. Une vérification peut prendre du temps sur une boutique volumineuse. Lancez-la après la reprise de la synchronisation, pendant un essai distinct, et lisez son rapport.

La commande affichée ci-dessous demande une comparaison. L’option --re-migrate déclenche des écritures et peut remplacer la version d’une commande dans le stockage de destination. Gardez-la hors de la vérification initiale. Si le rapport signale un écart, identifiez la source active et les champs touchés. Un statut différent, un total ou une métadonnée d’extension demandent des vérifications propres. Si la version installée propose wc hpos diff <id_commande>, utilisez cette comparaison ciblée sur la copie avant de toucher aux données. Elle affiche les différences sans les corriger. Sa sortie peut contenir des valeurs de commande. Gardez-la dans l’espace autorisé. Une ligne technique inattendue ne justifie pas de copier manuellement toute la table. Faites examiner la commande et le code qui l’a modifiée avant d’envisager une correction ciblée.

Choisissez plusieurs commandes témoins en plus du rapport. Prenez une commande récente, une commande plus ancienne et un remboursement représentatif si le site en gère. Dans l’administration WooCommerce, relevez les identifiants, les statuts, les montants et devises, le nombre de lignes, les réductions et le remboursement attendu. Vérifiez les écrans d’export ou les outils qui utilisent ces données. Une extension peut encore lire une ancienne source même lorsque l’administration présente la bonne valeur. Ce contrôle aide à distinguer une différence de stockage d’une intégration qui consulte le mauvais endroit.

1. Sur la copie, attendez la fin du traitement et relevez l’état des deux stockages.
2. Exécutez la vérification, puis lisez le rapport et les identifiants signalés. Gardez les données de client dans l’espace autorisé de la boutique.
3. Comparez les commandes témoins dans l’administration et dans les intégrations nécessaires. Pour un remboursement, vérifiez son rattachement à la bonne commande et le montant attendu.
4. En cas d’écart, gardez le stockage de référence et identifiez l’écriture ou l’intégration en cause. Refaites la comparaison après une correction confirmée.

wp --path='/chemin/vers/la-copie' --url='https://copie.exemple.invalid' wc hpos verify_data

Décider d’attendre, de corriger ou de préparer la bascule

Si les actions terminées se succèdent et que le compteur descend, gardez la configuration active et planifiez un nouveau relevé. Notez les heures et les volumes plutôt qu’une durée promise à partir d’un seul lot. Les performances de la copie, la quantité de données de chaque commande et l’activité de la boutique peuvent différer. Si les actions ne se lancent plus, remettez d’abord le planificateur en état. Si elles échouent sur les mêmes données, conservez les preuves et faites traiter la cause. Dans ces deux situations, changer le stockage de référence ajouterait une difficulté au diagnostic.

Lorsque le compteur atteint zéro, que la vérification ne montre pas d’écart inexpliqué et que les commandes témoins sont cohérentes, préparez la bascule selon la procédure de votre version. Relisez le stockage actif et le mode de compatibilité juste avant le changement. Vérifiez aussi les intégrations qui lisent les commandes et celles qui écrivent leurs propres métadonnées. Sur une boutique active, confirmez quels traitements pourront continuer pendant la fenêtre et comment les commandes reçues après le dernier contrôle seront vérifiées.

Pour un retour, vérifiez d’abord le sens de la synchronisation et l’état de la copie vers laquelle vous souhaitez revenir. Tant que HPOS fait foi, confirmez que le mode de compatibilité a rattrapé la copie historique avant de la sélectionner. Vérifiez aussi les modifications, annulations et remboursements intervenus depuis la bascule, ainsi que les nouvelles commandes. Si le compteur reste positif, si les témoins divergent ou si WooCommerce bloque la sélection, gardez le stockage actuel et traitez l’écart sans forcer le changement. Un fichier de sauvegarde récent peut aider à investiguer. Sa restauration complète sur la boutique peut pourtant retirer les écritures intervenues depuis. Préparez avec l’exploitant un retour qui tient compte de ces nouvelles commandes. Conservez les relevés de stockage, les journaux des actions et les différences constatées jusqu’à la validation.

Si la décision doit être transmise, donnez la version de WooCommerce, le stockage actif, l’état du mode de compatibilité, deux relevés horodatés et la première erreur pertinente. Ajoutez les vérifications témoins effectuées, avec des identifiants seulement si leur partage est autorisé. Le prochain opérateur pourra reprendre l’enquête au bon endroit et distinguer une file qui avance d’un écart qui empêche encore la bascule.