# WP_CACHE et advanced-cache.php : ce que wp-config.php active vraiment

> Une simple constante dans wp-config.php déclenche un mécanisme de chargement précoce que peu de développeurs WordPress ont déjà lu dans le code source du cœur.

- Auteur : WordPress Développement
- Publié le : 2024-06-14
- Mis à jour le : 2024-06-14
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/wp-cache-advanced-cache-php-wp-config-mecanisme/

## L’essentiel

- La constante WP_CACHE est vérifiée avant même le chargement des extensions
- advanced-cache.php doit exister à la racine de wp-content pour être chargé
- Une extension de cache mal désinstallée laisse parfois ce fichier orphelin

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

> L'essentiel à retenir : La constante WP_CACHE est vérifiée avant même le chargement des extensions ; advanced-cache.php doit exister à la racine de wp-content pour être chargé ; Une extension de cache mal désinstallée laisse parfois ce fichier orphelin

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 :

1. La constante est-elle définie et à quelle valeur, avec `wp eval 'var_dump(WP_CACHE);'` via WP-CLI ;
2. Le fichier `advanced-cache.php` existe-t-il physiquement à la racine de `wp-content` ;
3. 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.