Que retourne wp_cache_get( 'ma_cle' ) lorsque la clé n’existe pas dans le cache ? La réponse est false. Mais que retourne-t-elle aussi lorsque la valeur mise en cache est justement false, parce que c’est la réponse légitime d’un calcul coûteux ? Exactement la même chose. Ce chevauchement est une source d’erreurs discrète, qui pousse à recalculer une valeur alors qu’elle était déjà correctement en cache.
La fonction wp_cache_get() prévoit justement un quatrième paramètre pour lever cette ambiguïté, souvent ignoré faute d’être mis en avant dans les exemples les plus courants.
Le piège concret
Imaginons une fonction qui vérifie si un utilisateur a le droit d’accéder à une ressource, et met le résultat en cache pour éviter de refaire le calcul à chaque chargement de page. Le résultat peut légitimement être false — l’utilisateur n’a pas le droit — et ce résultat mérite d’être mis en cache exactement comme un résultat positif.
$autorise = wp_cache_get( 'droit_acces_' . $user_id, 'mon_groupe' );
if ( false === $autorise ) {
// Erreur : ce test ne distingue pas
// « pas en cache » de « en cache et false ».
$autorise = calculer_droit_acces_couteux( $user_id );
wp_cache_set( 'droit_acces_' . $user_id, $autorise, 'mon_groupe' );
}
Avec ce code, chaque utilisateur sans droit d’accès déclenche un recalcul à chaque chargement de page, alors que le cache contenait déjà la bonne réponse. Le cache existe, mais son intérêt est annulé par un test mal formulé.
La solution : le paramètre $found
$autorise = wp_cache_get( 'droit_acces_' . $user_id, 'mon_groupe', false, $trouve );
if ( ! $trouve ) {
$autorise = calculer_droit_acces_couteux( $user_id );
wp_cache_set( 'droit_acces_' . $user_id, $autorise, 'mon_groupe' );
}
La variable $trouve, passée par référence en quatrième argument, est modifiée par wp_cache_get() pour indiquer si une valeur a réellement été trouvée dans le cache, indépendamment de ce que cette valeur contient. Le test devient alors fiable, quelle que soit la nature du résultat mis en cache.
Signature complète de la fonction
| Paramètre | Rôle |
|---|---|
$key | Clé de cache à lire |
$group | Groupe de cache, vide par défaut |
$force | Force un rechargement depuis le backend externe si vrai |
&$found | Variable par référence, mise à vrai ou faux selon le résultat |
Pourquoi ce piège reste fréquent
- La plupart des tutoriels d’introduction au cache d’objets se limitent à un test
if ( false === $valeur ), suffisant tant que la valeur mise en cache n’est jamais elle-mêmefalseounull. - Le problème ne se manifeste qu’en production, sur les cas où la vraie réponse est justement la valeur ambiguë, ce qui le rend difficile à détecter en développement si les jeux de test ne couvrent pas ce cas.
- Un profilage avec Query Monitor peut révéler ce genre de recalcul répété, sans que la cause soit immédiatement évidente sans regarder le code source du callback concerné.
Un réflexe simple à adopter : dès qu’une valeur mise en cache peut être
false,nullou0, le quatrième paramètre dewp_cache_get()n’est plus optionnel, il devient la seule façon correcte d’écrire le test.
En résumé
Le paramètre $found de wp_cache_get() est discret dans la documentation, mais indispensable dès que la valeur mise en cache peut être falsy. L’ignorer ne provoque aucune erreur visible, seulement un cache silencieusement inefficace sur exactement les cas où il serait le plus utile.
