Cookies et sessions PHP WordPress – Tout ce que vous devez savoir

Les cookies ont été inventés pour la première fois en 1994 par un développeur informatique nommé Lou Montulli. Sans eux, le web serait un tout autre endroit. Que vous vous connectiez au back-end de votre site WordPress ou que vous fermiez une fenêtre popup gênante, vous utilisez et interagissez avec les cookies tous les jours (même si vous ne le réalisez pas).

Vous avez probablement deviné que lorsque nous faisons référence aux cookies, nous entendons par là les cookies utilisés pour stocker des informations importantes sur les visiteurs d’un site Web, et non les délicieuses pépites de chocolat. 🍪

Aujourd’hui, nous allons nous plonger dans le sujet parfois confus des cookies et des sessions PHP. En particulier, tout ce que vous devez savoir sur la façon dont WordPress les utilise, ainsi que certains problèmes courants que vous devez connaître (surtout en tant que développeur) lorsqu’il s’agit d’héberger votre site Web, de personnaliser du code ou d’utiliser un plugin tiers. À notre avis, ce sujet n’est pas assez abordé.

• Types de cookies
• Comment le noyau de WordPress utilise les cookies
• Comment les plugins et les thèmes WordPress tiers utilisent les cookies
• Les cookies et le cache WordPress
• Comment voir et effacer les cookies
• RGPD et Cookies
• Sessions PHP

Types de cookies

Il existe deux types de cookies différents qui sont généralement définis : les cookies de session et les cookies persistants.

Cookies de session

Les cookies de sessions, aussi appelés cookies transient, sont temporaires. Ils n’ont pas de date d’expiration et ne stockent que des informations sur ce que l’utilisateur fait pendant une seule session. Une session est simplement une valeur générée de façon aléatoire/unique qui est assignée lorsqu’une personne visite un site Web. Les cookies de session sont stockés temporairement en mémoire et sont automatiquement supprimés lorsque le navigateur se ferme ou quand la session se termine.

Lecture suggérée : Comment améliorer la limite de mémoire PHP dans WordPress.

Cookies persistants

Les cookies persistants, comme vous avez pu le deviner, sont ceux qui contiennent une date d’expiration. Ceux-ci durent beaucoup plus longtemps et sont stockés sur disque jusqu’à leur expiration ou sont effacés manuellement par l’utilisateur. Il s’agit des types de cookies que Google Analytics, AdRoll, Stripe, etc. utilisent.

Notre programme d’afiliation Kinsta est un autre exemple. Un cookie de 60 jours est placé dans le navigateur de l’utilisateur lorsqu’il clique sur un lien d’affiliation. Ceci permet de s’assurer que le parrain obtient le crédit approprié, même si la personne a fermé et rouvert son navigateur plusieurs fois.

Comment le noyau de WordPress utilise les cookies

Lorsque nous faisons référence au noyau WordPress, nous entendons simplement les fichiers qui composent le projet open source, avant d’installer tout plugin ou thème tiers. C’est WordPress à l’état naturel, comme nous aimons l’appeler.

Maintenant que vous connaissez les bases de ce qu’est un cookie et les différents types de cookies, voyons pourquoi et comment le noyau de WordPress les utilise pour que toute cette magie se produise dans les coulisses. Fait amusant : Cookie était à l’origine dérivé du terme « magic cookie« .

Le noyau de WordPress utilise les cookies à deux fins différentes :

1. Cookies de connexion

Les cookies de connexion contiennent des détails d’authentification et sont utilisés lorsqu’un utilisateur se connecte au tableau de bord d’administration WordPress. Selon le Codex WordPress, deux cookies de session différents sont définis :

• Lors de la connexion, WordPress utilise le cookie wordpress_[hash] pour stocker les détails d’authentification (limité à la zone /wp-admin/).
• Après la connexion, WordPress définit le cookie wordpress_logged_in_[hash]. Ceci indique quand vous êtes connecté et qui vous êtes.

Lorsque vous essayez d’accéder au back-end de votre site WordPress, une vérification est faite pour voir si les deux cookies ci-dessus existent et n’ont pas expiré. C’est ce qui vous permet de contourner magiquement l’écran wp-login.php. 😉

WordPress définit également les cookies wp-settings-{time}-[UID]. L’ID étant votre ID utilisateur de la table de base de données des utilisateurs de WordPress. Il stocke les paramètres personnels du tableau de bord et de l’interface d’administration.

2. Cookies de commentaires

Par défaut, il y a des cookies quand quelqu’un commente un article sur un blog (avec une expiration de 347 jours). Ainsi, s’ils reviennent plus tard, ils n’auront pas à remplir toutes les informations une nouvelle fois. Les trois cookies suivants sont stockés :

• comment_author_[hash]
• comment_author_email_[hash]
• comment_author_url_[hash]

Toutefois, avec les récents changements apportés à la politique de confidentialité en raison de le RGPD, de nouveaux outils ont été introduits parle noyau de WordPress pour s’assurer que vous laissez les utilisateurs choisir d’accepter que ces cookies soient installés. Ce paramètre, s’il n’est pas déjà défini, peut être activé sous « Paramètres → Discussion » dans votre tableau de bord d’administration WordPress. Cochez l’option « Afficher la case à cocher pour accepter les cookies sur les commentaires, ce qui permet l’enregistrement de cookies pour les auteurs de commentaires. ». Le populaire plugin Akismet vous permet également d’afficher un avis de confidentialité.

Comment les plugins et les thèmes WordPress tiers utilisent les cookies

Tout comme WordPress utilise des cookies pour certaines fonctionnalités, des plugins et des thèmes tiers que vous installez définissent également des cookies. La plupart d’entre eux utilisent une combinaison de cookies de navigateur et de lignes de base de données stockées dans la table wp_options ou leur propre table personnalisée. C’est parce que WordPress est“stateless”.

Une application “stateless” est un programme applicatif qui n’enregistre pas les données client générées au cours d’une session pour les utiliser lors de la session suivante avec ce client. Chaque session se déroule comme si c’était la première fois et les réponses ne dépendent pas des données d’une session précédente. – TechTarget

Avec les nouvelles lois sur la protection de la vie privée, il est plus important que jamais de comprendre quels cookies sont mis en place et s’ils offrent un moyen à vos visiteurs de s’inscrire. Astuce : tous les cookies ne nécessitent pas l’opt-in. Lisez notre article détaillé sur le RGPD pour mieux comprendre les nouvelles exigences.

Voici quelques exemples parmi tant d’autres de l’utilisation des cookies :

• Si vous avez une fenêtre popup sur votre site WordPress et qu’un visiteur la ferme, cela créera généralement un cookie pour que le popup ne revienne pas.
• Articles ajoutés à un panier d’achat sur votre site de eCommerce. Un cookie est stocké afin que le panier d’achat conserve vos produits pendant que vous continuez à naviguer sur le site.
• Les fonctions IP Geolocation peuvent stocker l’adresse IP et les coordonnées de latitude/longitude du visiteur qui navigue sur le site. Ceci est typiquement utilisé pour afficher un contenu spécifique à une certaine région ou peut-être même rediriger l’utilisateur vers un autre sous-site.
• Suivi de l’activité par clics avec un raccourcisseur de lien comme le plugin PrettyLinks.
• Le plugin Newsletter peut définir un cookie pour les utilisateurs s’ils sont déjà inscrits, ce 

Essentiellement toute action ou opt-in sur un site WordPress, implique généralement la mise en place d’un cookie dans le navigateur en arrière plan. L’objectif est, bien entendu, d’essayer d’améliorer l’expérience du navigateur ou de fournir des fonctionnalités supplémentaires par le biais de la vérification.

Voici tout ce que vous devez savoir sur WordPress et les cookies. Et nous ne parlons pas des délicieuses pépites de chocolat. 🍪Click to Tweet

Cookies WooCommerce

Les plugins de eCommerce tels que WooCommerce ont généralement leurs propres cookies supplémentaires qu’ils définissent pour que les acheteurs puissent facilement ajouter des choses à leur panier, stocker pour plus tard quand ils passent à la caisse, et se connecter et se déconnecter de leur compte.

Pour garder la trace des données du panier, WooCommerce place les trois cookies suivants (aucune information personnelle n’est stockée dans les cookies) :

• woocommerce_cart_hash
• woocommerce_items_in_cart
• wp_woocommerce_session_

Les deux premiers cookies contiennent des informations sur le panier et aident simplement WooCommerce à savoir quand les données du panier changent. Le troisième cookie wp_woocommerce_session_ contient un code unique pour chaque client qui correspond à une entrée dans la table wp_woocommerce_sessions personnalisée de la base de données.

Les données de wp_commerce_session_session étaient précédemment stockées dans la table wp_options, mais ont été déplacées vers sa propre table personnalisée dans WooCommerce 2.5 quand ils ont introduit un nouveau gestionnaire de session. Il s’agissait d’améliorer les performances, l’évolutivité et la gestion des sessions. Sinon, vous vous retrouvez rapidement avec une table wp_options gonflée que vous devez nettoyer.

Cookies Easy Digital Downloads

Easy Digital Downloads utilise par défaut WP_Session, qui est une combinaison de cookies de navigateur et de lignes de base de données stockées dans la table wp_options. Ci-dessous se trouve le cookie qu’il fixe :

• edd_items_in_cart

Les cookies et le cache WordPress

Quand il s’agit de cache WordPress, c’est là que les choses se compliquent. La mise en cache est essentiellement le processus de stockage des ressources d’une requête et de réutilisation de ces ressources pour des requêtes ultérieures. Fondamentalement, cela réduit la quantité de travail nécessaire pour générer une vue de page. Bien que cela soit excellent pour la performance, cela pose un problème lorsqu’il s’agit de cookies.

Pourquoi ? Parce que les cookies sont là pour effectuer une certaine action, comme garder le panier rempli pendant que vous naviguez sur un site WooCommerce. Cependant, si une page est servie à partir du cache, ni PHP ni la base de données ne font quoi que ce soit, le serveur sert simplement une copie statique de la page.

Alors, que pouvez-vous faire ?

1. Utiliser JavaScript

La première option serait d’utiliser JavaScript et de mettre à jour le contenu d’une page de façon dynamique. Fondamentalement, vous avez des espaces HTML réservés et utilisez JavaScript pour extraire des informations sur une API ou un appel ajax.

Un exemple serait de charger une liste d’articles dans la barre latérale de WordPress en utilisant JavaScript pour récupérer une liste d’articles via le wp-api et ensuite les afficher dans la barre latérale. Dans ce scénario, vous pourriez mettre à jour la liste des articles sans vider le cache de la page puisque les données sont générées dynamiquement.

Ce n’est pas l’idéal cependant, il est toujours préférable de mettre en cache si possible en termes de performances. Mais si vous devez avoir un peu de contenu dynamique alors que la page elle-même peut rester statique (servie à partir du cache), c’est une façon de le faire – utilisez JavaScript pour extraire le contenu de cette partie de la page de façon dynamique via un appel API/ajax. Cependant, à moins que vous ne puissiez engager un développeur WordPress pour construire une solution JavaScript personnalisée ou une extension d’un plugin, cette option n’est généralement pas pratique.

2. Utiliser les appels Admin-Ajax

Admin-ajax.php ne peut pas être mis en cache, vous pouvez donc utiliser les appels admin-ajax. Un bon exemple de ceci est le plugin No Cache AJAX Widgets. Il fait des appels admin-ajax et n’a donc pas à s’inquiéter d’un conflit avec les solutions de mise en cache de niveau serveur ou tierce partie.

Cependant, tout comme avec JavaScript, suivre cette voie n’est généralement pas faisable pour l’utilisateur moyen. Cela peut également entraîner d’autres problèmes de performance tels qu’une utilisation élevée d’admin-ajax et un grand nombre de requêtes non mises en cache.

3. Exclure des pages du cache (lorsque le cookie est présent)

À moins que vous ne puissiez utiliser JavaScript ou admin-ajax, la meilleure façon de procéder est d’exclure les pages du cache lorsqu’un cookie spécifique est présent. C’est typiquement ce que nous recommandons, en particulier ceux qui utilisent des sites très dynamiques tels qu’avec WooCommerce et Easy Digital Downloads.

Chez Kinsta, certaines pages de WooCommerce et de Easy Digital Downloads, comme le panier, mon compte et la caisse, sont automatiquement exclues du cache. Il y a une règle au niveau du serveur en place pour que les utilisateurs contournent automatiquement le cache lorsque le cookie woocommerce_items_in_cart ou edd_items_in_cart est détecté pour assurer un processus de paiement fluide et synchronisé.

Nous écoutons également les cookies connectés associés et configurons le cache pour qu’il ne passe pas lorsque nous détectons que quelqu’un s’est connecté à WordPress. Cela empêche le tableau de bord du back-end d’être accidentellement mis en cache.

Par défaut, nous n’excluons pas le cookie wp_woocommerce_session_ du cache. La plupart des sites WooCommerce de notre expérience n’ont aucun problème. Cela améliore également les performances en augmentant le ratio HIT de votre cache, tout en utilisant moins de workers PHP.

Cependant, étant donné qu’il existe de nombreuses configurations de thèmes et de plugins WordPress, nous pouvons exclure le cookie wp_woocommerce_session_ du cache si besoin. Contactez simplement notre équipe d’assistance. Le résultat est qu’une fois qu’un utilisateur ajoute un produit à son panier d’achat, toutes les demandes ultérieures ne seront pas servies à partir du cache, ce qui augmente l’utilisation de PHP par les utilisateurs.

Si vous avez besoin d’une page personnalisée exclue du cache, n’hésitez pas à ouvrir un ticket avec notre équipe de support. Encore une fois, il faut être prudent lorsqu’il s’agit d’exclusions. Trop de pages non mises en cache pourraient vraiment détériorer les performances. Consultez nos choses à faire et à ne pas faire pour héberger des sites d’adhésion WordPress.

Comment voir et effacer les cookies

Il est facile de voir et d’effacer les cookies sur un site Web. Pour voir quels cookies sont installés sur un site spécifique, naviguez sur ce site et cliquez sur le petit cadenas en haut de l’écran. Cliquez ensuite sur « Cookies ».

Ensuite, descendez jusqu’au dossier de ce site Web. Dans l’exemple ci-dessous, vous pouvez voir que nous avons quelques cookies WooCommerce, ainsi que le cookie wordpress_logged_in_[hash]. Vous pouvez également voir l’heure d’expiration et s’il s’agit d’un cookie persistant ou d’un cookie de session (lorsque la session de navigation se termine).

Pour supprimer un cookie, il suffit de cliquer sur un cookie individuel et de cliquer sur le bouton « Supprimer ». Vous pouvez également le faire au niveau du dossier ou dans Chrome DevTools.

La suppression des cookies peut également vous aider à corriger l’erreur 304.

Vous pouvez également rechercher ou supprimer tous les cookies dans votre navigateur.

RGPD et Cookies

La RGPD est une nouvelle loi sur la protection de la vie privée qui est entrée en vigueur le 25 mai 2018. Elle a été conçue pour permettre aux citoyens de reprendre le contrôle de leurs données personnelles. Nous vous recommandons fortement de lire notre article en profondeur : Le point sur la conformité au RGPD pour les utilisateurs de WordPress si vous ne l’avez pas déjà fait. C’est un sujet qui ne se résume pas en un paragraphe !

Voici un exemple d’un changement que nous avons apporté à Kinsta pour nous aider à nous conformer à la nouvelle loi. Lorsque vous visitez notre site pour la première fois, vous l’avez peut-être déjà vu, un message « Accepter les cookies » s’affiche en bas de l’écran. C’est parce que nous sommes maintenant légalement tenus de fournir aux utilisateurs un moyen d’opt-in et opt-out des cookies en cours d’installation. Fini le temps où il suffisait d’exécuter ce que vous voulez sans informer les utilisateurs de la collecte de données.

Si vous cliquez sur « Accepter les cookies », tous les cookies sont alors configurés pour l’utilisateur. Si vous cliquez sur « Paramètres des cookies », nous vous offrons maintenant la possibilité de choisir d’accepter ou de refuser les cookies que vous souhaitez.

Plutôt chouette, non ? Notre solution de cookie a été construite en interne par nos développeurs, mais voici quelques plugins WordPress pour le RGPD qui peuvent vous aider à accomplir quelque chose de similaire. Encore une fois, les témoins ne sont qu’une petite partie de la mise en conformité complète avec le RGPD.

Les sessions PHP

Les sessions PHP sont une alternative à l’approche standard des cookies. C’est toujours un cookie, mais il s’appelle PHPSESSID et est généralement stocké dans le répertoire /tmp/ du serveur web lui-même. La façon dont le serveur sait associer une session donnée à une requête donnée est qu’elle est également stockée dans un cookie HTTP.

Ceci peut également être vu sous l’en-tête HTTP d’un site.

Une session PHP ressemble beaucoup à une session normale qui se termine lorsque l’utilisateur ferme son navigateur.

Le problème avec les sessions PHP se résume à des problèmes de performances et de mise en cache. Les informations stockées dans le cookie du navigateur doivent rebondir à chaque demande afin que le serveur sache qui est l’utilisateur. Cela signifie que pour les sites qui utilisent PHPSESSID, l’hébergeur doit définir PHPSESSID pour contourner le cache. Cependant, le résultat est que PHPSESSID devrait être configuré pour contourner 100% du temps, car contrairement à wordpress_logged_in, le PHPSESSID est configuré sur chaque requête PHP unique.

Imaginez donc que wordpress_logged_logged_in doive être réglé 100% du temps pour que la fonctionnalité de connexion fonctionne. Cela signifie que même les utilisateurs déconnectés devraient avoir le cookie et qu’il devrait être unique pour eux. Imaginez que cela était nécessaire pour que le système de connexion WordPress fonctionne. Dans ce scénario, chaque page vue devrait contourner le cache afin que le cookie wordpress_logged_logged_in soit correctement configuré à la fois pour les utilisateurs connectés et déconnectés.

C’est le problème avec PHPSESSID. Parce qu’il est généré sur chaque requête PHP, si un site s’appuie sur les cookies PHPSESSID, l’hébergeur devra configurer PHPSESSID pour contourner le cache 100% du temps. Sinon, les PHPSESSID finissent par être mis en cache et les fonctionnalités qui en dépendent s’en trouvent perturbées.

Nous ne recommandons pas l’utilisation de sessions PHP et elles ne fonctionneront généralement pas dans notre environnement Kinsta. Les sessions PHP ont également d’autres implications en termes de sécurité qui devraient être prises en compte.

Si vous voyez du code utilisant session_start sur votre site, cela signifie qu’il utilise des sessions PHP.

De nombreux développeurs de plugins et de thèmes sont passés à l’utilisation d’une combinaison de cookies de navigateur et de lignes de base de données (soit dans la table wp_options, soit dans leur propre table personnalisée). Si vous avez besoin de données de session, c’est la meilleure approche.

N’hésitez pas à contacter notre équipe de support si vous avez des questions supplémentaires concernant les sessions PHP.

Résumé

Avec un peu de chance, vous en savez maintenant un peu plus sur le fonctionnement des cookies WordPress et des sessions PHP qu’auparavant. Les cookies sont actuellement ce qui fait tourner le monde et sont importants pour à peu près tout ce qui se passe sur un site WordPress. Qu’il s’agisse de nous garder connectés, d’assurer une expérience de commande en douceur ou même de s’assurer qu’une fenêtre popup reste fermée.

Vous avez d’autres questions sur les cookies ? 🍪 Faites-le nous savoir ci-dessous dans les commentaires.