Un panier d’achat qui se souvient de son contenu de page en page, un formulaire en plusieurs étapes qui garde les réponses précédentes : ces comportements demandent une mémoire que HTTP, protocole sans état, ne fournit pas nativement. La session comble ce manque côté serveur : les données sont stockées là (en mémoire, en base, dans un fichier), et seul un identifiant compact voyage jusqu’au navigateur, en général dans un cookie.
Sessions dans WordPress
WordPress n’utilise pas les sessions PHP natives ($_SESSION) pour la connexion de son back-office : il repose sur un système de cookies signés et vérifiés via wp_validate_auth_cookie(), sans stockage serveur équivalent à une session PHP classique. En revanche, WooCommerce implémente sa propre gestion de session (classe WC_Session_Handler), stockée en base de données, pour faire persister le panier d’un visiteur non connecté d’une page à l’autre.
Exemple
Cookie: PHPSESSID=a1b2c3d4e5f6...Côté serveur, ce seul identifiant permet de retrouver un tableau de données associé à ce visiteur précis.
À ne pas confondre avec
- Le cookie lui-même, qui n’est que le porteur de l’identifiant : les données réelles de la session vivent côté serveur, pas dans le cookie.
- Un compte utilisateur permanent : une session peut exister pour un simple visiteur anonyme (panier, préférences temporaires), sans qu’aucune authentification n’ait eu lieu.
- Le cache de page, qui doit généralement exclure les pages dépendant d’une session active (panier, compte), sous peine d’afficher les données d’un visiteur à un autre.