Le tableau de bord affiché à Marc contient les commandes de Julie. Ce genre de signalement, tout développeur WordPress finit par le recevoir un jour, généralement accompagné d’une capture d’écran incompréhensible et d’un ton pas franchement patient côté client.
La cause est presque toujours la même : un cache de page — qu’il s’agisse de WP Super Cache, W3 Total Cache, ou d’un cache serveur en amont — génère un fichier HTML statique pour une URL donnée, puis le sert tel quel à tous les visiteurs suivants, sans se soucier de savoir si le contenu affiché dépend d’un compte connecté.
Pourquoi le cache de page ignore la session
Un cache de page fonctionne à un niveau où la notion même de session PHP n’existe plus : il intercepte la requête avant que WordPress n’ait le temps de vérifier qui est connecté, et renvoie directement un fichier déjà généré. Le gain de performance est réel — on évite entièrement l’exécution PHP et les requêtes SQL — mais il suppose que la page rendue est identique pour tout le monde.
Le problème surgit dès qu’une page combine contenu public et contenu personnalisé : un tableau de bord client, une page de compte, un espace membre affichant le prénom de l’utilisateur ou son historique de commandes. Sans intervention explicite, ces pages entrent dans le même circuit de cache que n’importe quel article statique.
La solution : DONOTCACHEPAGE
DONOTCACHEPAGE est une constante reconnue par la quasi-totalité des extensions de cache de page pour WordPress, à commencer par WP Super Cache et W3 Total Cache. Quand elle vaut true au moment où la page se génère, l’extension de cache court-circuite sa propre logique et laisse WordPress traiter la requête normalement, sans jamais écrire ni lire de version statique de cette page précise.
add_action( 'template_redirect', function () {
if ( is_page( 'mon-compte' ) && is_user_logged_in() ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
} );
Le point critique tient au moment où cette constante est définie : elle doit l’être avant que l’extension de cache ne décide de servir ou non une version statique, donc le plus tôt possible dans le cycle de chargement. Un hook tardif comme wp_footer arrive généralement trop tard : la décision de mise en cache a déjà été prise.
Cibler précisément les pages concernées
Définir la constante sur l’intégralité du site reviendrait à désactiver le cache partout, ce qui annule tout l’intérêt de l’extension. L’enjeu est donc de cibler uniquement les gabarits concernés :
- Les pages de compte utilisateur, quel que soit le système d’authentification utilisé.
- Les pages affichant un contenu conditionné par une capacité ou un rôle (
current_user_can()). - Les pages de paiement ou de panier, où l’état change à chaque visiteur.
- Toute page construite avec des données de session ou de cookie personnalisées.
Pour ces gabarits précis, le coût en performance est largement compensé par la garantie qu’aucune donnée personnelle ne se retrouve affichée au mauvais visiteur.
Le cas des caches en amont de WordPress
Certains environnements ajoutent un cache HTTP en amont même du serveur PHP, par exemple via un proxy ou un CDN. Dans ce cas, DONOTCACHEPAGE n’a aucun effet, puisque la requête n’atteint jamais WordPress une fois qu’une version en cache existe déjà à ce niveau. Il faut alors agir sur les en-têtes HTTP eux-mêmes, généralement en s’assurant qu’un en-tête Cache-Control: no-store ou équivalent est envoyé sur les pages concernées, ou en configurant une exclusion explicite au niveau du proxy pour les chemins sensibles.
Vérifier que l’exclusion fonctionne réellement
Un moyen simple de confirmer que la page échappe bien au cache consiste à comparer deux requêtes successives avec un identifiant unique affiché temporairement, comme un horodatage précis. Si la valeur change à chaque rechargement, la page n’est effectivement pas mise en cache. Si elle reste figée, la constante est définie trop tard, ou une autre couche de cache — objet, opcode, proxy — intervient indépendamment du cache de page.
Sur un projet où plusieurs couches de cache se superposent, tester systématiquement en navigation privée avec deux comptes distincts reste le réflexe le plus fiable pour repérer une fuite avant qu’un client ne la signale.
Prévenir plutôt que corriger dans l’urgence
La bonne pratique consiste à intégrer cette exclusion dès la mise en place initiale d’un cache de page, en dressant la liste des gabarits personnalisés du projet avant même d’activer l’extension. Attendre qu’un incident remonte pour s’en préoccuper expose inutilement des données à un mauvais visiteur, potentiellement pendant plusieurs jours avant qu’un signalement n’arrive.
En résumé
Un cache de page HTML est aveugle à l’état de connexion par nature, pas par défaut mal configuré. DONOTCACHEPAGE reste le moyen le plus direct de lui signaler qu’une page précise doit toujours être générée à la volée. Le réflexe à garder : la définir tôt, la cibler précisément, et vérifier concrètement son effet plutôt que de la supposer active.
