Cache issue on bp directory pages with multisite installtion

[mhawksey]

In a multisite installation with object cache bp_core_get_directory_pages() returns incorrect directory pages as wp_cache_get() are not site isolated. From bp-core-functions.php:

// Look in cache first
$pages = wp_cache_get( 'directory_pages', 'bp' );

This results in errors on BP component pages:

Warning: in_array() expects parameter 2 to be array, null given in ... /plugins/buddypress/bp-core/bp-core-filters.php on line 192

A similar issue was discussed in #5733 but the fix does not extend to bp_core_get_directory_pages() or other 'bp' grouped caches.

We’ve fixed our own install with:

add_filter('bp_core_get_directory_pages', 'bp_core_get_directory_pages_cache_mod'); 

which suffixes the cache group with the root blog id. My concern is that this is not the only cache call. For further info we are using BP Multi Network plugin for the multisite installation.

[DJPaul]

@johnjamesjacoby You're probably the best versed in our cache group madness, and multi-networks. Can you confirm this, please?

[johnjamesjacoby]

Hi mhawksey,

Thanks for creating this ticket, and congrats on your first!

You're correct that this global cache group is not ideal, and there are a few places that still use it that should probably get moved off.

If you're taking advantage of WordPress's object-cache.php drop-in, something like this in your build_key( $key, $group ) method should clear everything up for you:

// Check for BuddyPress cache groups
if ( ( 'bp' === $group ) || ( 'bp_' === substr( $group, 0, 3 ) ) || in_array( $group, array( 'activity_meta', 'blog_meta', 'group_meta', 'message_meta', 'notification_meta', 'xprofile_meta' ) ) ) {

	// Prefix the network ID
	$network_id = get_current_site()->id;
	$group      = "network_{$network_id}:{$group}";
}

In the above snippet, you can see that we are targeting all BuddyPress specific cache groups, and keying them by the $network_id vs. the blog/site ID. If you're using the BP Multi Network plugin, this is probably the way to go, as it ensures each network activated BuddyPress setup gets its own unique cache prefix based on the ID of the network that all other sites are connected to.

The problem with this snippet is, frankly, the burden of maintaining a white-list of cache groups. We've talked about trying to include helper functions for this in the past, but there are so few people this impacts that we haven't talked very seriously about it in a long while.

Try this out, and please report back if it's working as intended, or if I can help in some other way. If you can identify an improvement to BuddyPress core, I'd also like to chat more about what that looks like here.

I also have an updated fork of the BP Multi Network plugin available on Github, that you might have better luck with: ​https://github.com/johnjamesjacoby/bp-multi-network

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/