[wp-trac] [WordPress Trac] #47884: Unable to remove "counts" from non persistent cache groups

[WordPress Trac]

#47884: Unable to remove "counts" from non persistent cache groups
--------------------------------------+------------------------------
 Reporter:  Maciej Laskowski          |       Owner:  (none)
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Cache API                 |     Version:  2.6
 Severity:  normal                    |  Resolution:
 Keywords:  dev-feedback 2nd-opinion  |     Focuses:  performance
--------------------------------------+------------------------------

Comment (by boonebgorges):

 The changesets that @desrosj linked to are all I'm able to find about the
 history of the 'counts' group, and the fact that it's nonpersistently
 cached.

 You'll notice that [7986] made the `'comment'` group non-persistent. We
 reversed this in #36906. To fix it, we needed a thorough audit of the ways
 in which the cache is used throughout core, and then a sweep through to
 ensure invalidation, as appropriate. Something similar would need to
 happen for `'counts'` if we wanted to make that group persistent as well.

 Since `wp_cache_add_non_persistent_groups()` doesn't actually do anything
 in WP itself - each cache drop-in has its own implementation of it - I
 don't think there's anything we can do about the fact that WP "adds it
 back". I guess I can see a place for
 `wp_cache_remove_non_persistent_groups()` or something similar, but this
 would only be a stub function in WP; it'd need to be implemented in the
 Redis drop-in, and then you'd need to call it *after* WP establishes its
 default non-persistent cache groups. As @desrosj, you can already do a
 version of this in your own drop-in, without any changes in WordPress. The
 main consequences of adding such a stub to WP would be to encourage dropin
 maintainers to implement the functionality in their drop-ins, and to
 encourage developers to make non-persistent into persistent caches. But
 this doesn't feel like the kind of thing we should encourage, since it's
 an invitation to introduce cache bugs - non-persistent caches are that way
 for a reason. To me it feels wiser to leave it out of WP, while
 acknowledging that developers like yourself who are aware of the potential
 fallout from improper invalidation are able to roll your own
 implementation in the cache drop-in.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47884#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform