Effacement des caches lors de la désinstallation du plug-in
Lorsqu'un plugin est désinstallé, il doit supprimer toutes les données associées du site (ou du réseau, si plusieurs sites sont disponibles). Si un plugin ajoute des tables à la base de données, par exemple, il doit supprimer ces tables de la base de données.
Ma question concerne un cas comme celui-ci où le plug-in est en réalité _doing_it_right() et met en cache certaines des requêtes qu'il effectue sur ces tables de base de données, à l'aide des fonctions wp_cache_*().
Je pense que lorsque le plugin est désinstallé, il devrait probablement vider ces caches. Mon raisonnement est que parfois, l'utilisateur peut réinstaller le plug-in après la désinstallation (par exemple, s'il venait de le tester et qu'il voulait effacer les données de test et recommencer à zéro). Si les caches ne sont pas effacés lors de la désinstallation, le plug-in risque de récupérer ces données fantômes des caches après leur réinstallation, provoquant ainsi un comportement très étrange.
Bien sûr, cela concerne surtout les sites qui auraient une mise en cache persistante. (Et cela serait exacerbé pour ceux qui ont une assez grande quantité de stockage, car les données obsolètes seraient probablement conservées plus longtemps.)
Pour tous les sites avec un back-end de mise en cache persistant activé, il n’est pas idéal de conserver un ensemble de données obsolètes stockées dans un plug-in désinstallé.
L'inconvénient d'essayer de vider ces caches est qu'il n'y a aucun moyen de vider tout un groupe de caches. Le plug-in devra parcourir tous les ID des objets de la table de base de données et vider le cache pour chacun d'eux. Il existe donc un compromis entre l'utilisation de la ressource et le nettoyage du cache.
Ma question est la suivante: quelqu'un d'autre a-t-il envisagé de décider si les caches de plug-in devraient être effacés lors de la désinstallation, et quand le compromis en vaut la peine? Est-ce une bonne pratique connue?
Il existe différentes approches à cet égard, en fonction des besoins spécifiques.
Par exemple, dans votre cas, vous semblez plus préoccupé par la prise de plug-in de données fantômes que les données laissées. Un tel cas pourrait être plus facile à gérer en générant un préfixe de clé unique à utiliser et en le vidant lors de la désinstallation. Pas de préfixe = pas d'accès aux données.
Je dirais que le cas général consiste à ignorer le problème et à utiliser des valeurs de délai d'attente appropriées pour les transitoires. Si les données ne sont pertinentes que pour une durée spécifique, l'utilisation du délai approprié les gère implicitement.
Les options peuvent (devraient) être stockées en un seul jeu, il est donc facile et rapide de les effacer.
Oui, cela devrait être le cas, d'autant plus que le cache peut contenir des informations sensibles que l'utilisateur peut souhaiter supprimer avec le plug-in.
La meilleure chose à faire est de concevoir votre système de manière à supprimer facilement toutes les informations persistantes - par exemple, placez tous vos fichiers de cache dans un seul répertoire.
En ce qui concerne votre exemple, le cache ne devrait en principe pas faire partie d'un objet (ce n'est pas une description de celui-ci), votre problème est donc lié à la conception de vos objets, ce qui vous pose des problèmes pour vider le cache. Si votre seule option est un cache dans la base de données (et que cela me semble un symptôme d'optimisation précoce), utilisez une table différente pour cela.
Mettre à jour
Votre hypothèse selon laquelle les API wp_cache_* utilisent un stockage persistant est fausse. C’est en fait une hypothèse sous-jacente du code principal qu’ils ne sont ni persistants et quel que soit le moteur du cache, un "ramassage des ordures" est effectué de temps à autre (le noyau supprime rarement quoi que ce soit du cache). Les systèmes de cache qui ne font pas de garbage collection sont très spécifiques ou bogués, car si vous ne le faites pas, vous allez à un moment donné manquer de RAM/espace disque.
En outre, l’implémentation du cache peut ne pas prendre en charge la suppression (peu probable, mais des événements étranges se produisent de temps à autre), vous ne pourrez donc en aucun cas effacer les données.
En substance. D'une part, ce sont des outils tiers que vous pourriez ne pas avoir assez de contrôle pour vous assurer de supprimer quoi que ce soit, d'autre part, la plupart d'entre eux sont en pratique assez intelligents pour supprimer automatiquement vos données dans un délai raisonnable (moins d'une journée) faire de la question du nettoyage un "agréable à avoir" mais totalement pas indispensable.
Et oui, les gens utilisent redis pour le cache, mais IMO, c'est une erreur. redis est une base de données nosql et non un cache RAM/distribué, bien qu'il puisse probablement être configuré pour être utilisé comme tel.