Panier WooCommerce vide ou ancien : retrouver la session et actualiser les données

Distinguer un panier perdu d’un affichage resté ancien

Vous ajoutez un produit, puis le panier paraît vide sur la page suivante. Ou vous retirez un article, mais le petit panier de l’en-tête continue à l’afficher. Ces deux symptômes peuvent venir de couches différentes : les données de la session, la réponse envoyée au navigateur ou l’élément qui les présente. Le résultat recherché est un même panier cohérent dans le parcours du même visiteur.

Ce guide concerne WordPress équipé de WooCommerce, avec un accès administrateur pour les réglages et les journaux. L’inspection du navigateur peut commencer sans modification serveur. Sur un réseau multisite, sélectionnez la bonne boutique ; deux sites ne partagent pas automatiquement un panier. Une boutique utilisant une interface externe peut identifier son panier autrement que par les seuls cookies du site. Sur WordPress.com ou une offre gérée, certains réglages de cache et de réseau appartiennent au prestataire : utilisez son panneau ou transmettez-lui le relevé ciblé.

WooCommerce est une extension gratuite ; la conservation du panier relève de la boutique et de ses intégrations. Les diagnostics ci-dessous utilisent les outils déjà présents et n’exigent pas l’installation d’une extension supplémentaire.

Ne commencez pas par effacer toutes les sessions clients dans WooCommerce, État, Outils. Vous supprimeriez des paniers actifs sans déterminer la cause. Préservez aussi votre propre panier si vous en avez besoin : ouvrir une nouvelle fenêtre privée de diagnostic est préférable à la suppression immédiate de toutes les données du navigateur habituel.

Reproduire un seul parcours avec des repères précis

Choisissez un produit simple en stock, une quantité et un navigateur de test. Ajoutez-le une fois, ouvrez la page Panier, modifiez la quantité puis actualisez. Comparez le mini-panier, la page complète et le récapitulatif de commande, sans soumettre d’achat. Notez le premier endroit où la valeur diverge.

Gardez la même fenêtre pendant cette séquence. Deux appareils ou deux profils distincts peuvent avoir des paniers séparés. À l’inverse, plusieurs fenêtres privées du même profil Chrome partagent la session privée en cours. Pour obtenir une session privée neuve, terminez d’abord les tâches utiles et fermez toutes ses fenêtres, puis ouvrez-en une nouvelle. Si vous vous connectez entre les étapes, notez ce changement : le traitement du panier d’un client connecté peut différer de celui d’un visiteur. Une différence après connexion ne prouve pas à elle seule un cache fautif.

Observez l’adresse complète à chaque passage : nom de domaine, présence de www, HTTPS et sous-dossier. Un lien vers une ancienne boutique ou une autre adresse peut vous faire quitter le contexte dans lequel le panier a été créé. Ne corrigez pas les deux adresses WordPress au hasard : elles peuvent différer volontairement lorsque l’installation se trouve dans un sous-dossier.

Regardez aussi les messages de WooCommerce. Un produit modifié, devenu indisponible ou non achetable peut être retiré du panier avec une explication. Un panier vidé après une commande réussie ne représente pas le même problème qu’une perte avant achat. Conservez le message exact au lieu de le masquer par du style.

• Page complète correcte, mini-panier ancien : examinez l’actualisation du composant.
• Page et récapitulatif réellement vides après ajout : examinez session, requête et changement d’adresse.
• Ancien contenu servi à plusieurs visites : examinez les caches et leurs exclusions.
• Un seul produit retiré avec une notification : vérifiez d’abord son état et les règles commerciales.

Parcours 1 : vérifier la page Panier affectée à la boutique

Ouvrez WooCommerce, Réglages, Avancé et relevez la page Panier assignée. Ouvrez cette page dans Pages, Toutes les pages. Vérifiez son contenu avec la Vue en liste : un bloc Panier, un code court classique ou un module de constructeur doit réellement fournir les données du panier. Une simple mise en page portant le titre Panier ne remplit pas cette fonction.

Si la mauvaise page a été sélectionnée, conservez son affectation initiale, choisissez la page Panier déjà prévue et enregistrez. Les fonctions Panier, Commande et Mon compte doivent rester distinctes. Vérifiez ensuite que le lien public du panier ouvre cette page et non une ancienne page conservée après une migration.

Si le contenu correct a été remplacé accidentellement, récupérez sa version sauvegardée sur une copie isolée avant de la rétablir. Le code court ci-dessous concerne le parcours classique : il se place dans un bloc Code court de la page Panier assignée. Ne l’ajoutez pas en doublon sous un bloc Panier existant pour tenter de forcer les mises à jour.

Le résultat attendu est une page qui affiche le contenu actuel de la session et permet d’en vérifier les quantités. Le retour arrière consiste à remettre l’affectation et le contenu sauvegardés. Cette opération ne demande pas de restaurer toute la base ni de toucher aux commandes existantes.

Si la page est correcte mais n’affiche pas le produit ajouté dans la même session, poursuivez avec le cache et les cookies. Si seule l’icône d’en-tête reste ancienne, gardez la page correcte comme point de comparaison pour le parcours consacré au mini-panier.

1. Relevez la page Panier dans WooCommerce, Réglages, Avancé, puis son adresse publique.
2. Ouvrez cette page dans l’éditeur et identifiez son unique bloc, code court ou module de panier.
3. Sur la copie, restaurez seulement l’affectation ou le contenu confirmé comme erroné ; enregistrez la page et les réglages concernés.
4. Ajoutez le produit témoin et vérifiez le lien public ainsi que les quantités.
5. Si la correction ne convient pas, restaurez ces deux valeurs sauvegardées, sans toucher aux commandes.

[woocommerce_cart]

Retirer les réponses personnelles du cache partagé

Les pages Panier, Commande et Mon compte présentent des informations propres au visiteur. Elles doivent rester dynamiques dans chaque couche : extension, hébergement, CDN ou proxy. Un administrateur connecté peut contourner un cache rencontré par les visiteurs ; vérifiez donc aussi le parcours sans connexion administrative, avec votre panier de diagnostic.

LiteSpeed Cache exclut normalement ces trois pages lorsqu’elles sont correctement affectées à WooCommerce. Une liste Do Not Cache URIs vide ne prouve donc pas qu’elles sont mises en cache. Commencez par vérifier l’affectation et la réponse reçue. Si un cache situé devant le serveur réutilise la page, une exclusion dans WordPress seule ne le corrige pas.

Pour une exclusion manquante confirmée, utilisez les chemins réels dans LiteSpeed Cache, Cache, Excludes, Do Not Cache URIs. Ce champ compare des portions d’adresse ; le caractère ^ limite la correspondance au début du chemin. L’exemple ci-dessous suppose des pages exactement situées sous /panier/, /commande/ et /mon-compte/ à la racine. Remplacez chaque chemin par celui de votre boutique, avec son éventuel sous-dossier ou préfixe de langue. N’insérez pas ces règles dans un fichier PHP.

LiteSpeed Cache est un outil gratuit, cité seulement s’il est déjà présent ; ses fonctions de cache serveur dépendent d’un environnement compatible. Ne l’installez pas pour dépanner un autre cache. Le résultat attendu est un panier personnel à jour après ajout, modification et rechargement. Conservez les exclusions nécessaires même si une autre cause explique la panne. Retirez uniquement une règle d’essai erronée après avoir confirmé que les pages restent protégées du cache partagé.

1. Conservez les règles existantes avant modification ; ajoutez seulement les chemins manquants, un par ligne, puis enregistrez.
2. Ouvrez LiteSpeed Cache, Toolbox, Purge, puis Purge By. Choisissez URL, saisissez les adresses concernées une par ligne et utilisez Purge List. Cette purge des pages ne purge pas les fichiers CSS ou JavaScript.
3. Dans le navigateur de diagnostic non connecté, ouvrez Réseau, rechargez le panier et sélectionnez la requête du document principal.
4. Dans les en-têtes de réponse, X-LiteSpeed-Cache-Control: no-cache confirme le contournement de cette couche LiteSpeed. Son absence seule ne prouve pas un cache partagé : examinez aussi les en-têtes et règles du CDN ou du proxy.
5. Refaites le parcours et vérifiez les réponses dynamiques du panier. Si un cache externe demeure en cause, corrigez et purgez seulement ses règles concernées avec son responsable ; n’effacez pas les sessions clients.

^/panier/
^/commande/
^/mon-compte/

Parcours 2 : vérifier si le navigateur conserve la session

Un cookie de session est une petite information que le navigateur renvoie pour permettre à la boutique de retrouver les données du visiteur. Dans les outils de développement de Chrome, ouvrez Application, puis Stockage, Cookies et le domaine de la boutique. Après un ajout de produit, cherchez notamment un cookie dont le nom commence par wp_woocommerce_session_. Ne copiez pas sa valeur dans un rapport public.

La même zone permet de lire domaine, chemin, expiration et attributs de sécurité. La présence du cookie ne prouve pas à elle seule que le serveur retrouve les données correspondantes. L’absence avant toute interaction n’est pas forcément anormale. Observez surtout son état après l’ajout et ce qui est envoyé sur la page suivante.

Dans Réseau, ouvrez la requête d’ajout puis celle du panier. Examinez les informations Cookies et les éventuelles raisons de refus indiquées par le navigateur. Comparez les domaines et le protocole. Si un cookie est défini pour un autre hôte ou ne peut pas être envoyé sur la destination, conservez cette preuve précise avant de modifier l’infrastructure.

Pour un problème limité à votre navigateur, comparez une session privée réellement neuve en conservant les choix de confidentialité nécessaires au parcours. Si le panier fonctionne dans ce contexte, examinez les extensions du navigateur ou les anciennes données du site dans votre profil habituel. Si un nettoyage est justifié, relevez d’abord les produits de votre panier : la suppression des données locales n’est pas annulable et peut vous déconnecter. Dans les paramètres Chrome, ouvrez Confidentialité et sécurité, Cookies tiers, puis Voir toutes les données et autorisations des sites. Recherchez le domaine exact et supprimez seulement son entrée, puis confirmez. Ne nettoyez pas tous les sites.

Le résultat attendu est une session retrouvée lors des passages successifs, sans refus de cookie pertinent. Si tous les navigateurs échouent de la même façon, n’allongez pas arbitrairement la durée de vie des cookies. Cherchez plutôt le changement d’hôte, le refus ou le défaut serveur identifié. La correction d’un réglage de navigateur se limite à ce qui a été modifié et doit respecter les choix de confidentialité du visiteur.

1. Ajoutez le produit témoin dans la session de diagnostic et ouvrez Application, Stockage, Cookies, puis le domaine.
2. Filtrez sur wp_woocommerce_session_ et relevez uniquement présence, domaine, chemin et expiration, sans modifier la valeur.
3. Dans Réseau, ouvrez la requête suivante vers le panier puis Cookies : vérifiez si le cookie est envoyé et si un avertissement apparaît.
4. Comparez cette requête avec l’adresse attendue ; retenez le premier changement d’hôte ou refus constaté.
5. Corrigez seulement la cause identifiée, puis reprenez la même séquence avant de nettoyer des données supplémentaires.

Corriger le changement d’adresse ou le blocage réellement observé

Si le panier fonctionne jusqu’à un lien précis, relevez sa destination avant et après redirection. Une ancienne adresse codée dans un bouton peut envoyer le visiteur vers une autre boutique. Corrigez ce lien dans la page ou le composant qui le produit, avec les droits d’édition nécessaires, en reprenant la page Panier assignée. Conservez la destination initiale pour pouvoir annuler cette modification ciblée.

Si le changement provient d’une redirection serveur, demandez au responsable de comparer sa règle avec le domaine public attendu et les chemins de la boutique. Une installation en sous-dossier ou derrière un proxy ne se corrige pas en rendant toutes les adresses identiques. La preuve utile est le passage précis qui fait changer de contexte, accompagné du résultat sur la session.

Un outil de consentement peut aussi retarder des scripts ou empêcher une fonction nécessaire au panier. Vérifiez le composant et sa configuration à partir de la requête ou du cookie refusé. Faites corriger la règle fonctionnelle appropriée selon la documentation de l’outil et la politique du site. Ne supprimez pas la bannière ni tous les contrôles de consentement pour faire réussir l’essai.

Le résultat attendu est le maintien du même contexte commercial pendant le parcours autorisé. Refaites ajout, ouverture du panier et modification de quantité depuis l’adresse publique prévue. Pour annuler une correction de lien inadaptée, rétablissez sa valeur sauvegardée ; pour une règle réseau, conservez une procédure de retour avec la personne qui l’a modifiée. Aucun de ces changements n’exige d’effacer les paniers de tous les clients.

Parcours 3 : actualiser le mini-panier avec son propre mécanisme

Si la page Panier contient les bons produits mais que le petit panier reste ancien, ne concluez pas que la session a disparu. Le thème peut afficher un widget classique ou un bloc Mini-panier, avec des mécanismes d’actualisation différents. Identifiez ce composant dans l’en-tête, le constructeur ou les widgets avant de corriger ses scripts.

Le widget classique peut utiliser les fragments de panier, de petits morceaux de contenu actualisés après une modification. Dans Réseau, recherchez une requête liée à get_refreshed_fragments lorsque ce mécanisme est réellement utilisé. Son absence ne démontre pas une panne sur un bloc Mini-panier, qui peut fonctionner avec la Store API. Ne forcez pas le chargement global des fragments sur toutes les pages pour masquer une intégration incorrecte.

Pour les blocs, filtrez Réseau sur wc/store, sélectionnez l’échange du panier puis l’onglet Réponse. Comparez les produits et quantités au panier complet ; un statut 200 seul ne démontre pas des données correctes. Selon les permaliens, la route peut apparaître dans un paramètre rest_route plutôt que sous /wp-json/. Un échange refusé ou une réponse ancienne doit être corrigé à sa source. Ne partagez pas les jetons de panier observés dans les en-têtes : certaines intégrations les utilisent pour identifier et manipuler le panier.

Sur la copie isolée, comparez le mini-panier sans l’optimisation de scripts qui semble bloquer son actualisation. Utilisez l’option d’exclusion de page ou de script documentée par l’outil existant, puis purgez les ressources générées nécessaires. Gardez la page Panier correcte comme témoin. Réactivez la transformation pour vérifier si le même défaut revient.

Si le composant appartient au thème ou à un constructeur, examinez sa compatibilité et sa version avant remplacement. Une correction ciblée de son intégration peut être nécessaire. Conservez le composant et les paramètres initiaux pour revenir en arrière. Le résultat attendu est la mise à jour du nombre et du contenu après ajout et suppression, sans altérer les données correctes de la session.

Examiner les données serveur et les retraits normaux de produits

Si les requêtes sont correctes mais que la session ne conserve pas le contenu, rapprochez l’heure de l’essai des journaux de la boutique et de l’hébergement. Une erreur de base, un cache d’objets mal configuré ou une extension qui réécrit le panier demande des preuves spécifiques. Ne supprimez pas les tables de session pour essayer de repartir de zéro.

La durée de session dépend du contexte et peut être personnalisée. Les valeurs par défaut du code distinguent visiteurs et utilisateurs connectés ; elles ne constituent pas une promesse de conservation illimitée. Un cookie supprimé par le navigateur, une déconnexion ou un changement d’utilisateur peut modifier le résultat. Allonger la durée ne répare pas un panier perdu immédiatement.

Examinez les notifications de retrait de produit. WooCommerce peut écarter une entrée dont le produit n’est plus disponible ou a changé de manière incompatible avec les données conservées. Vérifiez dans Produits le produit et la variation réellement sélectionnés : publication, état d’achat et disponibilité. Ne forcez pas dans le panier un article que la boutique ne peut plus vendre.

Sur une copie à base distincte, courriels, paiements et synchronisations réelles neutralisés, comparez ensuite sans l’extension de panier ou de tarification désignée par les journaux. Désactivez-la depuis Extensions installées, puis refaites le même scénario si les dépendances le permettent. Réactivez pour confirmer la relation. Évitez cette comparaison sur les paniers actifs des clients.

Le résultat attendu est soit un retrait commercial expliqué, soit une cause technique reproductible. Rétablissez les composants qui ne sont pas responsables et ne transférez pas la base de test sur la boutique active. La correction doit préserver commandes, comptes et paniers récents.

Contrôler le panier complet après la correction

Validez une séquence courte : ajouter un produit, ouvrir Panier, modifier sa quantité, retirer une ligne puis rejoindre la commande. Comparez le mini-panier et le récapitulatif à chaque étape. Une valeur correcte uniquement après un rechargement manuel peut encore signaler une actualisation défaillante.

Répétez le parcours pour un visiteur et, si la boutique le prévoit, pour un client connecté avec son propre compte de test. Gardez le même navigateur dans chaque séquence. La comparaison entre deux sessions différentes ne doit pas être présentée comme une synchronisation automatique attendue entre appareils.

Notez les exclusions de cache conservées, le composant corrigé et les valeurs remises à leur état initial. Si vous avez effacé uniquement vos données locales pour comparer, rappelez-vous que cela ne corrige pas la configuration des autres visiteurs. Inversement, une correction serveur peut fonctionner sans modifier leur panier existant ; ne leur demandez pas un nettoyage généralisé sans nécessité observée.

Le panier est rétabli lorsque ses données restent cohérentes dans le parcours prévu et que son affichage suit les actions du visiteur. Si le contenu devient correct mais que les paiements restent absents ou que la validation finale bloque, poursuivez sur ce diagnostic précis. Aucun effacement collectif n’est nécessaire pour déclarer cette cohérence vérifiée.