Que fait exactement define( 'WP_CACHE', true ); une fois écrit dans wp-config.php ? La réponse tient en une phrase mais mérite d’être détaillée, parce qu’elle explique une bonne partie des comportements étranges observés quand une extension de cache de page complète est mal installée, mal désinstallée, ou en conflit avec une autre.
Cette constante ne configure aucun paramètre de cache par elle-même. Elle indique simplement à WordPress qu’il doit chercher, très tôt dans son cycle de chargement, un fichier nommé advanced-cache.php à la racine de wp-content, et l’inclure avant même de charger la majorité de ses propres fonctions.
Le déroulé exact dans wp-settings.php
Le fichier wp-settings.php, chargé très tôt dans wp-load.php, contient une vérification explicite de la constante WP_CACHE :
if ( WP_CACHE ) {
WP_DEBUG && error_reporting( E_ALL );
require_once WP_CONTENT_DIR . '/advanced-cache.php';
}
Ce chargement intervient avant l’initialisation de la base de données WordPress classique, avant le chargement des extensions actives, et même avant la définition de la plupart des fonctions du cœur. C’est précisément ce qui permet à une extension de cache de page complète de servir une page entièrement statique, directement depuis un fichier ou une mémoire partagée, sans jamais solliciter PHP-FPM au-delà de ces quelques lignes.
Pourquoi advanced-cache.php n’est pas un fichier d’extension classique

Une extension de cache comme celles qui s’appuient sur ce mécanisme ne place pas sa logique principale dans son propre dossier sous wp-content/plugins, à la manière d’une extension ordinaire chargée via le système de hooks. Elle dépose une copie de son fichier de cache directement à la racine de wp-content, à l’endroit précis où wp-settings.php ira le chercher. C’est ce placement particulier qui explique pourquoi désactiver l’extension depuis l’interne de WordPress ne suffit pas toujours à arrêter le cache : la constante WP_CACHE reste vraie dans wp-config.php, et le fichier advanced-cache.php reste physiquement présent et continue d’être chargé, indépendamment de l’état d’activation de l’extension dans la table wp_options.
Le cas du fichier orphelin
Un scénario fréquent en support technique : une extension de cache est désinstallée proprement depuis l’administration, mais son processus de désinstallation ne supprime pas correctement advanced-cache.php, ni la constante dans wp-config.php. Le site continue alors de charger un fichier de cache orphelin, qui référence parfois des classes PHP appartenant à une extension qui n’existe plus, provoquant une erreur fatale du type Class 'WP_Super_Cache' not found au tout début du chargement, avant même que WordPress n’ait la moindre chance d’afficher un message d’erreur exploitable.
Le nettoyage manuel dans ce cas précis nécessite deux interventions distinctes, l’une sans l’autre étant insuffisante :
rm wp-content/advanced-cache.php
puis dans wp-config.php :
define( 'WP_CACHE', false ); // ou suppression complète de la ligne
Comment vérifier l’état réel du mécanisme
Trois vérifications suffisent à établir un diagnostic fiable, plutôt que de deviner à partir des seuls symptômes visibles :
- La constante est-elle définie et à quelle valeur, avec
wp eval 'var_dump(WP_CACHE);'via WP-CLI ; - Le fichier
advanced-cache.phpexiste-t-il physiquement à la racine dewp-content; - Une entête de réponse HTTP confirme-t-elle qu’une page servie provient bien du cache, la plupart des extensions ajoutant un commentaire HTML ou une entête personnalisée à cet effet.
Un mécanisme volontairement rustique
Ce système date des débuts du cœur de WordPress et n’a jamais été remplacé par une API de cache de page plus formelle, en partie parce qu’il fonctionne, et en partie parce que les besoins des différentes extensions de cache divergent trop pour qu’une API unique fasse consensus. Le mécanisme reste donc, plusieurs versions majeures plus tard, une simple vérification de constante suivie d’un require_once, sans validation ni garde-fou supplémentaire au niveau du cœur.
Comprendre
advanced-cache.phpévite de perdre une heure à chercher un bug dans une extension déjà supprimée depuis longtemps.
Ce qu’on retient
La constante WP_CACHE n’active aucun comportement en elle-même : elle ouvre simplement une porte que seul advanced-cache.php franchit réellement. Comprendre cette mécanique en deux étapes, la constante puis le fichier, permet de diagnostiquer en quelques minutes des problèmes de cache qui, sans cette lecture du code source, ressemblent à des bugs inexplicables de WordPress lui-même.