When a plugin is uninstalled, it should remove all related data from the site (or network, if on multisite). If a plugin adds tables to the database, for example, it should remove those tables from the database.

My question concerns a case like this where the plugin is actually _doing_it_right() and caching some of the queries that it makes on those database tables, using the wp_cache_*() functions.

I'm thinking that when the plugin is uninstalled it should probably clear those caches. My reasoning is that sometimes the user might reinstall the plugin after uninstalling (for example if they were just testing it out and want to erase the test data and start fresh). If the caches aren't cleared on uninstall, the plugin might retrieve that ghost data from the caches after it was re-installed, causing very strange behavior.

Of course, this is mostly a concern for those sites that would have persistent caching of some sort. (And it would be exacerbated on those with a pretty big large amount of storage, since the stale data would likely be retained longer.)

For any site with a persistent caching back-end enabled though, having a bunch of stale data sitting in there from an uninstalled plugin is not ideal.

The downside of trying to clear those caches is that there is no way to clear a whole cache group. The plugin would have to loop through all of the IDs of the objects in the database table and clear the cache for each one. So there is resource-usage trade-off between clearing the cache and leaving it.

My question is, has anybody else considered whether plugin caches should be cleared on uninstall, and when the trade-off is worth it? Is this a known best practice?

up vote 1 down vote accepted

There are different approaches to this, depending on specific requirements.

For example in your case you seem more worried about plugin picking up ghost data than that data being left behind. Such case might be easier handled by generating unique key prefix to use and just flushing that on uninstall. No prefix = no data access.

I would say the general case is to ignore the issue and to use appropriate timeout values for transients. If data is only relevant for specific amount of time then using appropriate timeout handles it implicitly just fine.

Options can (should) be stored as single set, so clearing those out is easy and fast.

  • Yeah, I clear all options and user meta, etc., using the built-in WordPress functions, which will take care of clearing those caches for me. The idea of generating a unique prefix for plugin-specific caches on install is intriguing. That's something that I hadn't thought of, and it would definitely work for this. I guess that you're right though and usually this is an issue that plugin authors just ignore. I guess a site owner could just dump their cache after uninstalling a plugin if they found it necessary. – J.D. Jul 4 '16 at 18:52
  • Actually, maybe I misunderstood what you meant by the prefix. I was thinking that you were suggesting to generate a unique prefix each time the plugin was installed. Reading your answer again I see that you were just suggesting to clear the cache by key prefix. The problem is that as far as I know there is no way to do that. ... Wait, just read the answer again, and maybe I was right the first time. I guess the way you have it written it comes across as ambiguous to me. :-) – J.D. Jul 4 '16 at 18:55
  • Transients are not cleared from the DB so there must be a smart usage of them to be able to delete them. – Mark Kaplun Jul 5 '16 at 0:07
  • @J.D. I meant former, though clearing by prefix is possible as well (only for default DB transient storage though). – Rarst Jul 5 '16 at 7:27
  • @MarkKaplun expired transients are now cleared from DB on core updates, they gave in on the issue of zillions of them piling up and clogging storage being an issue. – Rarst Jul 5 '16 at 7:28

Yes, they should be, especially since cache might contain sensitive information the user might wish to be removed with the plugin.

Best thing is to design your system in a way in which it is easy to delete all persistent information - for example place all your cache files under one directory.

As for your example, cache in theory should not be part of an object (it is not a description of it in any way), therefor your problem is with the design of your objects which leads to your problems with clearing the cache. If your only option is a cache in the DB (and it sounds to me like a symptom of early optimization) then use a different table for it.


Your assumption that wp_cache_* APIs use a persistent storage is false. It is actually an underlining assumption of core code that they are nor persistent and whatever is driving the cache does a "garbage collection" from time to time (core rarely delete anything from the cache). Caching systems that do not do garbage collection are either very specific or buggy as if you don't do it you are going at some point to run out of RAM/disk space.

In addition the cache implementation might not support a delete (unlikely, but strange things do happen from time to time) therefor you will not be able to clear the data in any case.

In essence. on one hand those are 3rd party tools that you might not have enough control to be sure that you delete anything, on the other most of them in practice are smart enough to auto delete your data given some sensible enough time (less then a day) making the issue of cleaning it up a "nice to have" but totally not essential.

And yes, people do use redis for cache, but IMO it is a mistake. redis is a nosql DB, not a RAM/distributed cache although it probably can be configured to be used like one.

  • I think maybe my question wasn't clear. The caches aren't stored in the database tables. It is the data in the tables that might be caches using wp_cache_set(), etc. – J.D. Jul 4 '16 at 18:46
  • I've edited the question slightly to clarify this. – J.D. Jul 4 '16 at 18:47
  • @J.D. updated the answer – Mark Kaplun Jul 5 '16 at 0:24

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.