« Cette proposition vise à exposer, de façon standardisée, les capacités réelles du cache d’objets actif — persistance, groupes supportés, opérations atomiques — plutôt que de laisser chaque extension deviner ce comportement au cas par cas. » Ce résumé, publié sur make.wordpress.org à l’occasion de la fusion d’un ticket Trac dans le tronc de développement en vue de la prochaine version majeure, concerne directement tous ceux qui développent des extensions interagissant avec l’API de cache d’objets.
Le changement, encore en cours de stabilisation avant la sortie officielle de WordPress 7.0, mérite d’être suivi dès maintenant par quiconque construit une extension dont le comportement dépend de la présence ou non d’un cache persistant comme Redis ou Memcached.
Ce que change concrètement cette proposition
Jusqu’ici, une extension qui voulait savoir si un cache d’objets persistant était actif se contentait généralement d’appeler wp_using_ext_object_cache(), une fonction booléenne qui ne renseigne que sur la présence d’un cache externe, sans détailler ses capacités réelles. Impossible, par exemple, de savoir si ce cache supporte les opérations atomiques d’incrémentation, ou s’il gère correctement l’expiration par groupe.
La proposition fusionnée dans le tronc introduit une nouvelle fonction, wp_cache_supports(), qui accepte en argument le nom d’une capacité (par exemple 'flush_group' ou 'get_multiple') et retourne un booléen précis, sans avoir à interroger l’implémentation sous-jacente au cas par cas.
Nouveautés classées par impact pour les développeurs d’extensions
Impact fort : fin des tests de compatibilité approximatifs
Les extensions qui adaptaient jusqu’ici leur comportement en testant l’existence de fonctions spécifiques à un plugin de cache donné (par exemple en vérifiant la présence d’une classe propre à Redis Object Cache) pourront s’appuyer sur une API neutre, indépendante de l’implémentation réellement installée sur le site.
Impact moyen : un nouveau filtre pour les développeurs de plugins de cache
Les auteurs de plugins d’objet cache eux-mêmes gagnent un nouveau filtre, wp_cache_supports_capabilities, qui leur permet de déclarer précisément les capacités supportées par leur implémentation, plutôt que de laisser WordPress deviner un comportement par défaut potentiellement erroné.
Impact faible : aucune rupture de compatibilité ascendante prévue
Les anciennes fonctions, wp_using_ext_object_cache() en tête, restent disponibles et continueront de fonctionner à l’identique. La nouvelle API vient en complément, pas en remplacement, ce qui limite le risque de régression pour les extensions existantes qui n’adopteraient pas immédiatement le nouveau mécanisme.
Pourquoi suivre ce ticket avant la sortie définitive
- Tester dès maintenant ses propres extensions sur une version nightly de WordPress incluant cette proposition
- Signaler tout comportement inattendu directement sur le ticket Trac concerné, pendant qu’il est encore possible d’ajuster l’implémentation
- Préparer la documentation interne d’une extension pour expliquer la migration vers
wp_cache_supports()une fois la version stable publiée
Une proposition fusionnée dans le tronc de développement n’est pas encore une fonctionnalité stable ; c’est une invitation à tester avant que le comportement ne se fige définitivement.
En résumé
Cette évolution de l’API de cache d’objets, encore en phase de stabilisation avant la sortie de WordPress 7.0, promet de simplifier durablement le travail des développeurs d’extensions confrontés à des implémentations de cache hétérogènes. Ce billet ne couvre pas le cache de page, qui repose sur un mécanisme entièrement distinct de l’API de cache d’objets.
