# wp_cache_get avec force=true : le paramètre qui court-circuite le cache local

> Le cache d'objet semble constamment ignoré malgré Redis actif. Le diagnostic mène à un paramètre force activé par un plugin tiers dans ses propres appels.

- Auteur : Clément Hadrot
- Publié le : 2022-09-30
- Mis à jour le : 2022-09-30
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/wp-cache-get-force-true-court-circuite-cache/

## L’essentiel

- Le paramètre force oblige à relire la source même si une valeur existe déjà en cache local
- Un plugin qui l'active systématiquement annule le bénéfice du cache non persistant
- La correction consiste à isoler le groupe de cache concerné, pas à désactiver Redis

Le taux de hit affiché par Query Monitor reste étonnamment bas pour un site équipé d'un cache d'objet Redis correctement configuré et opérationnel selon toutes les vérifications habituelles. Certaines clés, pourtant lues plusieurs fois dans la même requête, apparaissent comme systématiquement recalculées plutôt que servies depuis le cache.

## Diagnostic : isoler les appels concernés

En activant une trace détaillée des appels à `wp_cache_get()` via un plugin de débogage, les appels problématiques partagent tous un point commun : ils proviennent du même plugin tiers de gestion de disponibilité de stock, et passent systématiquement `true` comme troisième argument de `wp_cache_get()`.

```
// Signature de la fonction, extraite du cœur WordPress
wp_cache_get( $key, $group = '', $force = false, &$found = null )
```

Ce troisième paramètre, nommé `$force`, indique au cache non persistant (celui valable pour la durée d'une seule requête PHP) qu'il doit ignorer toute valeur déjà présente localement et forcer une nouvelle lecture depuis le backend de cache configuré, Redis en l'occurrence. L'intention initiale du développeur du plugin était probablement de garantir une fraîcheur maximale sur des données de stock sensibles, mais l'effet de bord touchait l'ensemble des appels utilisant le même groupe de cache.

> L'essentiel à retenir : Le paramètre force oblige à relire la source même si une valeur existe déjà en cache local ; Un plugin qui l'active systématiquement annule le bénéfice du cache non persistant ; La correction consiste à isoler le groupe de cache concerné, pas à désactiver Redis

## Pourquoi ce paramètre annule un bénéfice attendu

Le cache non persistant sert normalement à éviter des lectures redondantes au sein d'une même requête HTTP : si une valeur a déjà été lue une fois depuis Redis pendant cette requête, un second appel identique la récupère directement en mémoire locale PHP, sans repasser par le réseau vers le serveur Redis. Avec `force=true`, chaque appel repasse systématiquement par ce réseau, même pour une valeur lue une fraction de seconde plus tôt dans le même script.

### Un effet amplifié par le groupe de cache partagé

Le plugin de gestion de stock utilisait le même groupe de cache générique que plusieurs autres fonctionnalités du site pour des raisons de simplicité de développement. Le paramètre `force`, bien qu'appliqué uniquement dans le code de ce plugin, se répercutait donc sur la perception globale du taux de hit affiché par les outils de diagnostic, sans toucher réellement les autres groupes de cache utilisés ailleurs sur le site.

## Correctif appliqué

1. Contact avec l'éditeur du plugin pour signaler l'usage de `force=true` hors d'un contexte qui le justifie réellement.
2. En attendant une correction officielle, isolation du groupe de cache du plugin dans un groupe dédié, via un filtre déclarant ce groupe comme non persistant pour les autres composants du site.
3. Vérification que seule la donnée de stock, réellement sensible à la fraîcheur, conservait ce comportement forcé, sans affecter les autres lectures.

## Prévention pour l'avenir

Avant d'utiliser `force=true` dans un développement personnalisé, il faut se demander si la fraîcheur immédiate est réellement requise à chaque appel, ou seulement à certains moments précis du parcours utilisateur (juste avant validation d'une commande, par exemple). Réserver ce paramètre à ces moments précis, plutôt qu'à l'ensemble des lectures d'une fonctionnalité, préserve le bénéfice du cache non persistant pour le reste du code.

## Comment tracer les appels forcés sans modifier le plugin

Pour confirmer le diagnostic sans avoir accès au code source du plugin dans un premier temps, un petit mouchard temporaire a été ajouté via le filtre disponible sur les groupes de cache non persistants, permettant de journaliser chaque appel effectué avec le paramètre forcé activé, sans jamais interrompre le fonctionnement normal du site :

```
add_filter('wp_cache_non_persistent_groups', function ($groupes) {
    error_log('Groupes de cache non persistants actuels : ' . implode(', ', $groupes));
    return $groupes;
});
```

Cette trace, combinée à un examen manuel du code source téléchargeable du plugin en cause, a suffi à confirmer que l'appel à `wp_cache_get()` avec `force=true` se trouvait dans une seule fonction du plugin, appelée à chaque affichage de fiche produit, ce qui expliquait la fréquence élevée observée dans le journal.

## En résumé

Un cache d'objet persistant correctement configuré peut malgré tout sembler inefficace si un paramètre discret, disponible depuis toujours dans `wp_cache_get()`, force une relecture systématique. Le diagnostic passe par une trace détaillée des appels, pas par une remise en cause immédiate de la configuration de Redis elle-même.