Qu’est-ce qui reste vraiment quand un visiteur ferme son navigateur après avoir ajouté trois articles à son panier WooCommerce ? La réponse dépend de deux objets distincts, souvent confondus par un développeur qui découvre WooCommerce : WC_Cart et WC_Session. Le premier vit le temps d’une requête PHP ; le second, lui, traverse les visites.
Cette distinction paraît abstraite tant qu’aucun bug ne force à s’y intéresser. Elle devient essentielle dès qu’il faut comprendre pourquoi un panier « disparaît » après une déconnexion, ou pourquoi une modification apportée à un total de panier ne survit pas au rechargement suivant de la page.
WC_Cart : un objet reconstruit à chaque requête
L’objet accessible via WC()->cart est une instance de WC_Cart, recréée à chaque chargement de page. Il contient la liste des articles, les quantités, les totaux calculés, les remises appliquées. Rien de tout cela ne vit en base de données sous cette forme : à chaque requête, WooCommerce reconstruit cet objet à partir de données plus élémentaires, stockées ailleurs, puis relance le calcul des totaux via WC_Cart::calculate_totals().
C’est pour cela qu’un développeur qui modifie directement les propriétés de WC_Cart en mémoire, sans passer par les hooks prévus comme woocommerce_before_calculate_totals, voit sa modification s’évaporer à la requête suivante : l’objet a simplement été reconstruit depuis zéro, sans mémoire de ce qui avait été bricolé la fois précédente.
WC_Session : la mémoire entre deux requêtes
La persistance minimale entre deux requêtes vient de WC_Session_Handler, la classe qui gère la session WooCommerce. Contrairement aux sessions PHP natives, WooCommerce stocke ses données de session dans une table dédiée de la base de données, wp_woocommerce_sessions, identifiée par un cookie contenant une clé de session plutôt que les données elles-mêmes.
Ce que la session contient réellement
La session ne stocke pas un objet WC_Cart complet et figé : elle conserve les données brutes nécessaires à sa reconstruction, notamment le contenu du panier sous forme de tableau sérialisé, les données de livraison choisies et les coupons appliqués. À chaque requête, WooCommerce lit cette session, reconstruit un objet WC_Cart à partir de ces données, puis relance le calcul des totaux comme si de rien n’était.
Une durée de vie par défaut de 48 heures
Par défaut, une session WooCommerce expire 48 heures après la dernière activité du visiteur. Passé ce délai, la ligne correspondante est supprimée de la table de sessions, et le panier associé disparaît avec elle pour un visiteur non identifié. Cette durée se règle via le filtre wc_session_expiration, utile pour une boutique dont le cycle d’achat est plus long, par exemple un site de vente de mobilier sur mesure où l’hésitation dure parfois plusieurs jours.
add_filter( 'wc_session_expiration', function() {
return 7 * DAY_IN_SECONDS;
});Panier connecté : une couche de persistance supplémentaire
Pour un client connecté, WooCommerce ajoute une troisième couche : le panier persistant, enregistré dans une métadonnée utilisateur nommée _woocommerce_persistent_cart_ suivie de l’identifiant du site. Cette copie survit même à l’expiration de la session ou à la suppression du cookie, et permet à un client qui se reconnecte sur un autre appareil de retrouver son panier tel qu’il l’avait laissé.
WC_Cart: objet en mémoire, recalculé à chaque requêteWC_Session: données brutes en base, persistantes le temps de la session- Métadonnée utilisateur : copie longue durée du panier pour un client connecté
Où cela casse en pratique
Un bug classique : un développeur ajoute un article au panier via une action personnalisée déclenchée trop tôt, avant que WooCommerce n’ait initialisé la session (avant le hook wp_loaded, par exemple). L’objet WC()->session n’existe pas encore à ce stade, et l’appel provoque une erreur silencieuse ou un panier qui reste obstinément vide malgré un code apparemment correct.
Avant de manipuler le panier depuis du code personnalisé, vérifiez toujours que la session WooCommerce est bien initialisée : beaucoup de paniers « vides à tort » viennent d’un hook déclenché trop tôt.
Ce que cette distinction ne couvre pas
Une fois la commande finalisée, ces mécanismes de panier et de session n’entrent plus en jeu : la commande est alors stockée de façon définitive comme objet WC_Order, dans les tables prévues à cet effet, indépendamment de toute notion de session ou d’expiration. Le stockage des commandes finalisées répond à des règles bien différentes, qui méritent un article à part entière.
Pour aller plus loin
Retenir la distinction entre ces deux objets évite bien des heures de débogage : si une donnée de panier disparaît trop vite, c’est probablement la session qui a expiré ; si une modification de panier ne survit pas à la requête suivante, c’est probablement WC_Cart qui a été modifié sans passer par les hooks prévus pour la persistance.
