Make WordPress Core

Opened 14 years ago

Last modified 6 months ago

#4476 reopened enhancement

Delete Cache by Group

Reported by: filosofo Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.2
Component: Cache API Keywords: needs-patch
Focuses: Cc:


Currently, you have to specify the id of the cached item in order to delete it via wp_cache_delete, or you have to flush the entire cache via wp_cache_flush.

Instead, it would be helpful if one were able to delete an entire group without having to flush all of the cache.

For example, term-related plugins could expect their particular caches to be deleted whenever changes to any terms were made, instead of having to use callbacks for every term-related action.

Attachments (1)

cache.php.diff (1.1 KB) - added by filosofo 14 years ago.

Download all attachments as: .zip

Change History (21)

14 years ago

#1 @filosofo
14 years ago

  • Keywords has-patch added

#2 @ryan
14 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#3 @ryan
14 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Cache has been gutted, so this is no longer relevant.

#4 @Nazgul
14 years ago

  • Milestone 2.5 deleted

#5 @sc0ttkclark
9 years ago

  • Cc lol@… added
  • Keywords dev-feedback added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version set to 2.2

Looks like the reason this was closed is no longer the case. What's the plan here? I want to delete all items for a specific group.

For now, I'll just work with the object itself, but there's a definite need for a function like wp_cache_delete_group or the patch as attached.

#6 @SergeyBiryukov
9 years ago

  • Component changed from Administration to Cache
  • Keywords cache wp_cache_delete removed
  • Milestone set to Awaiting Review

#7 @scribu
9 years ago

The reason this is not part of the API is that most persistent caching backend such as memcache don't support deleting an entire group.

What's done instead is increment the group prefix and let memcache's garbage collector remove the items from the old group, which are never accessed anymore.

#8 @scribu
9 years ago

  • Keywords close added; dev-feedback removed

#9 @sc0ttkclark
9 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Okay, sorry for my n00bness as I'm diving deeper into WP caching than ever before, but how would I increment the group prefix? Feel free to reply with a *slap*

#10 @scribu
9 years ago

Actually, you don't change the prefix of the group, but add a prefix to each individual key:

$ns_key = wp_cache_get( 'foo_namespace_key' );

// if not set, initialize it
if ( $ns_key === false )
  wp_cache_set( 'foo_namespace_key', 1 );

$my_key = "foo_".$ns_key."_12345";
$my_value = wp_cache_get( $my_key, 'some_group' );

To clear the namespace do:

wp_cache_incr( 'foo_namespace_key' );

Source: https://groups.google.com/forum/?fromgroups#!topic/memcached/Izov0cFjBXI

#11 @scribu
9 years ago

  • Milestone Awaiting Review deleted

#12 follow-up: @Ste_95
4 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Why hasn't this received any more attention? I still think it's relevant. The invalidation method posted by @scribu is good with memcached, but not if cached data goes to the database as a transient:

It is important to note that if you are not careful about how you are using this design pattern, you could accidentally consume all of your cache storage space. This strategy relies on changing the key that is used to access the cached object; it never removes the previously cached versions of the objects. It leaves it in the cache's storage. If your caching backend relies on a caching technology that does not automatically handle cache evictions, you may completely fill that storage. I tend to work with memcached on large projects that need efficient caching. Memcached implements an aggressive (sometimes way too aggressive) eviction policy whereby cached objects are frequently removed from cache. You can change the keys for the cached objects and the older objects will be removed from the cache, making room for newer versions of the objects. As such, the incrementor invalidation strategy is an effective tool in a memcached environment.


Why not implement the patch from @filosofo? Or at least provide a method to access the $cache class var, so that we could iterate through the category array and manually delete each key?

Last edited 4 years ago by Ste_95 (previous) (diff)

#13 @Ste_95
4 years ago

Any news on thys guy? @SergeyBiryukov tagging you as you seem to be the only one with recent activity.

#14 in reply to: ↑ 12 @dd32
4 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Replying to Ste_95:

Why hasn't this received any more attention? I still think it's relevant.

This was made irrelevant when WordPress removed persistent caching.
File-based Persistent caching was removed in WordPress 2.5 and switched to a non-persistent per-request cache instead, which removed the need to clear the cache like this.

The cache is designed to be replaced by a persistent in-memory cache such as memcache, redis, or any other number of cache backends. These do not generally allow deletion of an entire cache group, adding support to WordPress for it is therefor not exactly useful.

Why not implement the patch from @filosofo? Or at least provide a method to access the $cache class var, so that we could iterate through the category array and manually delete each key?

While we could enable this, it would cause your code to be not-very-portable, as soon as you used it on any site that had an external Object Caching dropin enabled, you'd see the code completely fail to operate as expected.

The invalidation method posted by scribu is good with memcached, but not if cached data goes to the database as a transient:

Transients are completely different to the wp_cache_*() functions, although transients do utilise them if an external cache is in use.
If you've got wp_cache_*() setup through a drop-in to use transients, then that's probably a bad move - it's really not designed to be used like that, and you'd be better off with that disabled in many scenario's I would assume.

You may want to look at how you're using transients if that's the case, and reconsider their usage. It sounds like you're using them in a way they weren't designed, or something similar. #20316 may interest you.

I'm re-closing this ticket as wontfix, you may comment here while the ticket is closed, but for the reasons outlined above, we won't be adding a Delete Cache by Group functionality right now, and probably not anytime soon.

#15 @dhilditch
3 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Instead of adding 'delete by group', to achieve the same desired functionality - namely, the ability to 'delete' chunks from the cache without wiping the entire cache - how about this approach:

  1. Add an extra parameter to wp_cache_get and wp_cache_set called 'namespace'
  2. When the namespace parameter exists, use the code given by @scribu to append a number to the $key param
  3. Add a new function wp_cache_clear_namespace with the namespace parameter - this function increments the namespace number so - in-effect - all items for this namespace are 'deleted'.

Otherwise EVERY developer has to keep coding their own versions of the code from @scribu both for getting items from the cache and for setting items in the cache, and most won't bother and instead will just flush the entire cache when their settings pages change which is entirely unnecessary and detrimental to the performance of large websites.

#16 @dougal
3 years ago

I have a current use-case where deleting by group would be useful -- a long-running report job where I want to track whether I've already processed certain items in the current queue run, then delete the cached hits after the report is done.

But yeah, since not all external caching mechanisms provide a mechanism for that functionality, and the dropins would have to be updated with the new method, I can see why it's wontfix. :-/

#17 @SergeyBiryukov
3 years ago

  • Milestone set to Awaiting Review

#18 @lucasbustamante
17 months ago

It would be nice if WordPress could enforce an object-cache API that the drop-ins could follow so we could use it reliably in plugin development.

For instance, Pantheon's Redis drop-in supports deleting a group of cache keys with wp_cache_delete_group( $group ):


While this other Redis drop-in with 60k+ installations does not:
https://wordpress.org/plugins/redis-cache/ (https://github.com/devgeniem/wp-redis-object-cache-dropin/blob/master/object-cache.php)

Automattic WP Memcached doesn't support groups, either: https://github.com/Automattic/wp-memcached/blob/master/object-cache.php

The solution I propose is that WordPress enforces an interface on cache drop-ins, so we can be sure that they will allow deleting groups. If Memcached needs some namespace hacks to work with groups, then that's handled internally by the drop-in.

#19 @SergeyBiryukov
16 months ago

  • Keywords close removed

Just noting that wp_cache_get_multiple() was added to wp-includes/cache-compat.php in [47939] / #20875 as a compat function for drop-ins that don't support it natively.

It seems like wp_cache_delete_group() could be added in the same way too.

#20 @dg12345
6 months ago

  • Keywords needs-patch added; has-patch removed

The main reason I can think to do this is that, currently to delete targeted cache you must use the "last_changed" method which essentially just adjust the keys used but that would also leave the old keys in the cache, so your redis or memcache will slowly get bigger.

The only other way is for you to keep track of all the keys used and write a script to delete each one when you want to delete the cache.

I agree with @lucasbustamante, simply putting it in as an official core function you will force the hand of the plugin writers to implement it in the main redis and memcache plugins.

I would think its a five minute job to add a delete by group function, the core doesn't even need to use it (although give the cache size issue it would be nice if it did).

Note: See TracTickets for help on using tickets.