Commande WooCommerce bloquée sur le chargement : retrouver la requête en échec

Ne pas recommencer un paiement à l’aveugle

La page de commande reste grisée, un cercle tourne ou le bouton ne retrouve jamais son état normal. Ce symptôme indique que le parcours n’a pas terminé son travail dans le navigateur. Il ne prouve pas que la commande a échoué, ni que le prestataire n’a rien encaissé. Le résultat recherché est une page utilisable, avec une seule commande et le bon résultat de paiement.

Si le blocage survient après le bouton Commander, ouvrez d’abord WooCommerce, Commandes dans une autre fenêtre d’administration. Recherchez l’achat par heure, montant et client. Contrôlez aussi la transaction dans l’espace du prestataire de paiement avec les droits nécessaires. Une commande existante ou un débit identifié doit être rapproché avant de demander une nouvelle tentative.

Ce guide concerne une boutique WordPress utilisant déjà WooCommerce, pas le cœur WordPress seul. Un administrateur de boutique doit pouvoir lire les réglages, les commandes et les journaux. Le réseau ou l’hébergement peut être nécessaire pour corriger un blocage serveur. Sur WordPress.com, les menus de la boutique peuvent être accessibles par WP Admin ; l’accès aux journaux serveur dépend du service.

La version WooCommerce examinée est 11.2.1, gratuite et éditée par Automattic. Elle déclare WordPress 7.0 et PHP 7.4 au minimum, avec un test déclaré jusqu’à WordPress 7.1.4. Les passerelles de paiement et modules de livraison possèdent leurs propres versions et compatibilités. Aucun remplacement de passerelle n’est nécessaire pour commencer le diagnostic. Ces minima de compatibilité ne sont pas une recommandation d’utiliser une ancienne branche PHP.

Noter le moment exact où la page se bloque

Distinguez trois moments : ouverture de la page, recalcul après une adresse ou un transport, puis validation finale. Si le blocage arrive avant toute soumission, il faut examiner le chargement du panier et des services nécessaires. S’il arrive après Commander, il faut aussi examiner la création de commande et l’appel au paiement. Ne mélangez pas les deux scénarios dans une même série d’essais.

Notez un produit, une quantité, l’adresse de destination, le transport, le paiement et l’état de connexion concernés. Utilisez des données de test lorsque vous reproduisez. Un problème limité à une zone de livraison n’a pas la même portée qu’une page inutilisable pour tous les paniers. Les informations déjà signalées par un client peuvent suffire à orienter la première lecture des journaux.

Préparez une copie isolée pour les manipulations qui pourraient interrompre la vente. Elle doit employer une base distincte. Neutralisez courriels vers les clients, notifications vers les applications réelles et intégrations commerciales avant l’essai. Déconnectez les passerelles réelles ou utilisez leur mode de test documenté avec ses propres identifiants. Si la validation test dépend d’une notification entrante du prestataire, conservez uniquement ce parcours de test correctement configuré : bloquer toutes les notifications empêcherait de vérifier le paiement.

Choisissez ensuite le parcours correspondant à la preuve recueillie. Une page mal assignée se corrige dans les réglages de page. Une réponse mise en cache demande une exclusion ciblée. Une erreur de script ou de serveur demande de retrouver le composant responsable. Changer le thème, le cache et le paiement simultanément empêcherait de savoir quelle correction agit.

Lire la requête qui ne se termine pas

Dans Chrome, ouvrez les outils de développement, puis Réseau ou Network avant le scénario. Activez Conserver le journal ou Preserve log. Regardez All pour repérer un document ou un script bloqué, puis Fetch/XHR pour les échanges de commande. Effacez seulement la liste affichée et reproduisez une fois le déclencheur sur la copie sûre. Sur une page bloquée en production, lisez d’abord les requêtes déjà présentes, sans nouvelle validation. Si les outils viennent d’être ouverts, l’historique absent n’est pas récupéré automatiquement.

Pour une commande classique, recherchez les requêtes contenant wc-ajax=update_order_review pendant le recalcul et wc-ajax=checkout lors de la soumission. Le bloc de commande utilise la Store API, avec des chemins sous /wp-json/wc/store/ ; les échanges de panier et de commande peuvent apparaître séparément. Une autre intégration peut ajouter ses propres requêtes.

Cliquez sur l’entrée en attente ou en erreur. Dans Headers puis Response, relevez l’adresse expurgée, la méthode, le statut, la durée et la réponse. Un statut 200 ne suffit pas : le JSON peut signaler un refus métier, ou une page HTML remplacer les données attendues. Ne rejouez pas une requête de validation avec Replay XHR ou une commande copiée. Un export HAR peut contenir cookies, jetons et données client ; partagez seulement les éléments nécessaires après retrait de ces informations.

Ouvrez aussi Console, effacez les anciennes entrées et relevez la première erreur pertinente au même moment. Les erreurs suivantes peuvent en être des conséquences. Notez le fichier ou le domaine concerné. Ne collez pas dans la console une commande trouvée sur un forum pour forcer la fin du paiement ou masquer l’indicateur.

Si la Store API signale un nonce invalide, c’est-à-dire un jeton de vérification de la requête, recherchez une page ancienne ou un décalage de session. Après correction du cache sur la copie, rouvrez le parcours pour obtenir une session cohérente. N’ajoutez pas un extrait qui désactive la vérification des nonces : il masquerait la cause en retirant une protection.

• Une réponse 403 appelle la recherche d’un refus de sécurité ou d’autorisation au même instant.
• Une réponse 404 appelle le contrôle du chemin, des redirections et du routage.
• Une réponse 500 appelle la lecture des erreurs serveur correspondantes.
• Une requête durablement en attente appelle la recherche d’un délai serveur ou d’un service externe.
• Une page de connexion ou de maintenance dans la réponse appelle le contrôle de la couche qui remplace la réponse attendue.

Parcours 1 : retrouver la page de commande réellement utilisée

1. Ce parcours convient si la mauvaise page s’ouvre, si un constructeur montre un ancien formulaire ou si les requêtes ne correspondent pas au type de commande attendu. Dans WooCommerce, Réglages, Avancé, relevez la page affectée à la commande. Ouvrez Pages, Toutes les pages, puis modifiez cette page précise. Conservez son contenu initial avant une modification.
2. Examinez la Vue en liste de l’éditeur. Un bloc Commande ou Checkout indique le parcours par blocs. Un bloc Code court contenant le formulaire WooCommerce indique le parcours classique. Un module de constructeur peut utiliser une autre intégration : vérifiez sa documentation et sa compatibilité, sans supposer qu’il se comporte comme le bloc natif.
3. Si une mauvaise page était affectée, choisissez la page de commande déjà préparée et correcte dans les réglages avancés, puis enregistrez. Les pages Panier, Commande et Mon compte doivent conserver leurs fonctions distinctes. Ne créez pas une deuxième page de paiement pour chaque essai et ne placez pas deux formulaires de commande concurrents dans la même page.
4. Si le contenu a été remplacé, travaillez d’abord sur la copie avec la version sauvegardée. Pour le parcours classique déjà retenu, ajoutez un bloc Code court dans la page assignée et collez uniquement le code ci-dessous ; utilisez Mettre à jour ou Enregistrer selon l’éditeur. Vérifiez qu’aucun second formulaire ne subsiste. Pour un parcours par blocs, restaurez son bloc Commande prévu. Ne remplacez pas automatiquement le bloc par un code court : les compatibilités des passerelles peuvent différer.
5. Le résultat attendu est une page assignée qui charge le formulaire prévu et des requêtes cohérentes avec ce formulaire. Le retour arrière consiste à rétablir l’affectation initiale et le contenu sauvegardé, sans restaurer les commandes de toute la base. Si l’affectation était déjà correcte, gardez-la et poursuivez avec la preuve réseau.

[woocommerce_checkout]

Parcours 2 : retirer la page dynamique du cache partagé

1. Cette méthode convient lorsque la réponse contient une copie ancienne, que le comportement diffère entre visiteur et administrateur ou qu’un diagnostic confirme un cache sur les échanges de commande. Commencez par les systèmes déjà utilisés : extension, cache d’hébergement, CDN ou proxy. Installer un second cache n’aide pas à comprendre le premier.
2. Les pages Panier, Commande et Mon compte doivent rester dynamiques. Vérifiez leurs adresses réelles dans les réglages avancés de WooCommerce, y compris le préfixe d’un sous-dossier ou d’une langue. Une exclusion visant seulement /checkout/ ne couvre pas une page française appelée /commander/. Vérifiez aussi que les échanges WooCommerce concernés ne reçoivent pas une réponse partagée entre visiteurs.
3. Si LiteSpeed Cache est déjà présent, ouvrez LiteSpeed Cache, Cache, puis Exclut ou Excludes. Dans Do Not Cache URIs, ajoutez uniquement les chemins réels manquants, un par ligne, en conservant les entrées existantes. Enregistrez. L’intégration peut déjà exclure ces pages ; ne multipliez pas les lignes si la réponse montre qu’elles ne sont pas mises en cache.
4. Dans LiteSpeed Cache > Boîte à outils ou Toolbox > Purge, repérez Purge By…, sélectionnez URL, inscrivez les adresses concernées une par ligne, puis Purge List. Ce parcours purge les pages, pas leurs fichiers CSS/JS. Si un cache d’hébergement ou de CDN sert encore le document, retirez aussi les copies de ces adresses dans ce service. La purge d’un niveau ne prouve pas que les autres sont actualisés.
5. Le résultat attendu est une réponse propre à la session du client et un recalcul terminé. Examinez les en-têtes disponibles, par exemple X-LiteSpeed-Cache quand cette couche les expose, et le contenu reçu. Un cache miss signifie seulement que cette réponse n’était pas servie depuis ce cache ; ce n’est pas une preuve d’exclusion permanente. Confirmez la règle et les contrôles de session. Retirez uniquement les exclusions ajoutées sans effet ; ne réactivez jamais une mise en cache publique de données client pour obtenir un score de performance.

Isoler une transformation JavaScript sans ajouter d’extension

Un script de commande peut être chargé mais exécuté trop tard, combiné dans un mauvais ordre ou bloqué. Ce cas se distingue d’une réponse serveur fatale. Si la console désigne un script ou si le problème est apparu après une optimisation, comparez la page sans cette transformation sur la copie isolée.

Avec LiteSpeed Cache déjà utilisé, ouvrez Optimisation de page, puis Réglages ou Tuning. Ajoutez le chemin exact de la page de commande dans URI Excludes pour l’exclure des optimisations de page, puis enregistrez. Cette option est distincte de Do Not Cache URIs : l’une concerne les transformations, l’autre le stockage de la réponse. Une seule exclusion ne remplace pas nécessairement l’autre.

Purgez la page concernée. Si des fichiers optimisés obsolètes interviennent, utilisez sur la copie Toolbox > Purge > Purge All - CSS/JS, en sachant que cette purge concerne les ressources générées de tout le site. Elle ne supprime pas les médias ou les commandes. Rechargez le scénario pour régénérer ce qui est nécessaire. Si la panne disparaît, réintroduisez les transformations une par une sur la copie pour identifier la fonction responsable.

La version gratuite LiteSpeed Cache 7.9.2 de LiteSpeed Technologies a été vérifiée : WordPress 6.0 et PHP 7.4 minimaux déclarés, test jusqu’à WordPress 7.1.4. Elle sert ici uniquement d’exemple de réglage d’un outil existant, sans recommandation d’installation. Ses fonctions de cache serveur dépendent de l’environnement compatible.

Le résultat attendu est une commande fonctionnelle lorsque la transformation responsable est exclue. Si aucun changement n’apparaît, retirez la ligne ajoutée et revenez aux réglages initiaux avant l’analyse suivante. Ne désactivez pas le consentement, le pare-feu ou la politique de sécurité du navigateur dans son ensemble pour faire disparaître une erreur de script.

Parcours 3 : retrouver le composant en erreur dans les journaux

1. Si la requête échoue côté serveur ou si l’exclusion ne change rien, ouvrez WooCommerce > État > Journaux. Dans Browse log files ou Parcourir les fichiers journaux, filtrez la date et la source pertinente, puis ouvrez le fichier. Les erreurs PHP fatales peuvent figurer sous fatal-errors. L’absence d’entrée dans ce fichier ne suffit pas à exclure une panne d’une autre couche.
2. Lisez quelques lignes autour de l’événement. Relevez la nature de l’erreur, le fichier cité, le moment et l’identifiant de commande s’il existe. Un avertissement ancien sans rapport avec la requête ne suffit pas à désigner une extension. Si l’erreur indique une mémoire épuisée ou un délai précis, transmettez ce message à l’hébergement plutôt que d’augmenter toutes les limites sans mesure.
3. Dans WooCommerce, État, État du système, récupérez le rapport pour votre diagnostic privé. Il aide à comparer versions, modèles remplacés et composants actifs. Retirez les données sensibles avant de le partager. Pour une requête bloquée avant WordPress, demandez aussi au responsable les journaux du pare-feu, du serveur web ou du proxy au même instant.
4. Sur la copie isolée, ouvrez Extensions, Extensions installées et désactivez le composant désigné, si le scénario peut encore fonctionner sans lui. Pour une passerelle indispensable, utilisez plutôt une combinaison minimale documentée et son mode de test. Gardez WooCommerce et les dépendances nécessaires à la reproduction. Conservez la liste des composants actifs avant la comparaison.
5. Réactivez ensuite le composant et vérifiez si la même panne revient avec le même scénario. Un seul essai devenu fonctionnel après plusieurs changements ne prouve pas un conflit déterminé. Si le thème est suspect, changez-le seulement sur la copie, avec un thème déjà disponible et compatible ; ne publiez pas ce changement de présentation comme simple expérience.
6. Le résultat attendu est une cause reproductible ou un message serveur exploitable. La correction peut être une mise à jour compatible, un réglage du composant ou une modification ciblée fournie par son éditeur. Rétablissez les éléments qui ne sont pas responsables. Ne copiez jamais toute la base de test vers la production pour déployer une correction de fichier : elle pourrait écraser les commandes récentes.

Traiter le service lent à partir de la requête observée

Si le navigateur attend durablement, rapprochez la requête des appels externes : transport, taxes, paiement ou courrier transactionnel. Le moment du blocage aide à choisir. Un calcul de livraison ne se répare pas en modifiant les notifications, et un courrier lent après création de commande ne justifie pas de supprimer la validation du paiement.

Consultez le journal du service réellement impliqué et son état officiel. Une réponse de refus doit être traitée selon sa cause : droits, configuration ou restriction documentée. Ne désactivez ni la vérification TLS ni les contrôles d’autorisation pour obtenir artificiellement une réponse. Un délai réseau ou une panne extérieure demande une correction différente d’une clé invalide.

Si un retard d’envoi est confirmé, la version examinée propose Deferred emails dans WooCommerce > Réglages > Avancé > Fonctionnalités. Sur la copie, conservez l’état initial, activez cette seule option puis enregistrez. Vérifiez dans État > Actions planifiées que les actions de courrier correspondantes aboutissent, et contrôlez la réception vers une adresse de test. Si l’essai n’est pas concluant, rétablissez l’option initiale ; surveillez les tâches déjà créées, que ce retour ne supprime pas automatiquement. Ce réglage ne corrige pas un chargement bloqué avant soumission.

Si la cause reste hors de votre accès, transmettez le type de commande, l’heure avec fuseau, la requête, le statut et l’erreur correspondante, avec les secrets retirés. Cette demande ciblée permet au responsable de corriger une règle ou un service précis. Elle vient après les contrôles réalisables, sans remplacer le diagnostic de la page et de la réponse.

Valider une seule commande complète et conserver le retour arrière

Après chaque correction, reprenez le même produit, la même adresse et le même moyen de paiement en mode test. Vérifiez d’abord que les totaux et les transports se recalculent. Pour une panne à la validation finale, terminez ensuite une commande de test et contrôlez la page de résultat ainsi que l’entrée créée dans WooCommerce.

Vérifiez qu’une seule commande correspond à cet essai et que son état concorde avec la transaction de test. Un indicateur disparu ne suffit pas si la réponse finale manque ou si les commandes se dupliquent. À l’inverse, une commande correctement créée mais laissée en attente après un encaissement relève du rapprochement du paiement, qui constitue un diagnostic distinct.

Documentez la valeur conservée, les composants concernés et les réglages remis à leur état initial. Avant déploiement, préparez le retour arrière de la seule correction : affectation de page, exclusion ou version compatible du composant. Préservez les nouvelles données commerciales ; une restauration globale n’est pas l’équivalent de l’annulation d’un réglage.

Sur la boutique active, contrôlez ensuite les parcours réellement autorisés, visiteurs et clients connectés, sans provoquer une série d’achats réels. Le résultat recherché reste concret : la requête se termine, la page confirme la bonne opération et le suivi commercial ne laisse aucun paiement ambigu à traiter.