[buddypress-trac] [BuddyPress Trac] #5733: Use wp_cache_add_global_groups() so cache is applicable throughout multisite

[buddypress-trac]

#5733: Use wp_cache_add_global_groups() so cache is applicable throughout
multisite
--------------------------+-----------------------------
 Reporter:  wpdennis      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Core          |     Version:  2.0
 Severity:  minor         |  Resolution:
 Keywords:  2nd-opinion   |
--------------------------+-----------------------------

Comment (by boonebgorges):

 johnjamesjacoby - I notice that your patch doesn't touch some of the other
 more specific cache buckets in BP - say
 https://buddypress.trac.wordpress.org/browser/tags/2.1.1/src/bp-groups/bp-
 groups-classes.php#L188. I assume that's because the cache keys themselves
 in those buckets are generally numeric, which would cause clashes between
 object types. (This mirrors WP's conventions for cache keys.) So, in order
 to make the system more flexible, I wonder if it makes sense to have
 something like `bp_get_cache_group( $group_type )`, to which you'd pass
 'groups' or 'activity' or 'core' or whatever, so you could modify any of
 our cache buckets however you'd like.

 Another thought that is more of a question that comes out of my limited
 knowledge of how various caching backends are configured: How much of the
 customization can we offload onto, eg, Memcached? I assume it's possible
 to set up, at the level of the cache config, rules about how to route the
 various cache groups (as in the case of multiple memcached servers, or
 whatever). I don't want to go too far in the direction of building
 customizability into BP that would be more efficiently handled in the
 caching layer itself.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5733#comment:16>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac