BP_Core->setup_globals is very expensive on child sites in a network (switch_to_blog())

[wpdennis]

In a network with BuddyPress enabled network wide, setup_globals() forces multiple switch_to_blog() on each page view on a child site, because of bp_get_option(). With things like bbpress (<2.3) this results in a lot (!) of db queries.

I reduced the load a little by adding this snippet in a ms plugin:

add_action('bp_init', function() {
	global $bp;
	if (empty($bp->root_domain))
		$bp->root_domain = 'http://www.example.com';
		
	if (1 != get_current_blog_id() and empty($bp->pages))
		$bp->pages = true; // not needed on child sites
}, 2);

But I'm not sure if it's too custom and maybe it's only working in my case. Four questions here:

1) Are there possible installations where you need things like $bp->pages on a child site while BuddyPress is network wide activated? If not, can we check this in setup_globals() and don't load $pages at all?

2) Can we add a constant like BP_ROOT_DOMAIN (for wp-config.php) to avoid bp_core_get_root_domain() on each page view for such a constant value?

3) Is it possible to use object cache for bp_core_get_root_options()? I'm not sure if cache invalidation is trivial in this case. Is there a central function which updates the options? If so, we can do it in like 5 lines of code and store the value in a global group.

4) bp_update_is_item_admin( bp_user_has_access(), 'core' ) is only neccessary for profiles, is it? If so, do we ever have profiles on a child site while BuddyPress is network wide activated?

[boonebgorges]

Thanks for pushing us on these issues, wpdennis. It's really valuable.

Are there possible installations where you need things like $bp->pages on a child site while BuddyPress is network wide activated?

Yes. We need $pages in order to build all BP content URLs - in particular, URLs of the form http://example.com/members/foo. Those URLs can be, and often are, used all over a network.

Can we add a constant like BP_ROOT_DOMAIN (for wp-config.php) to avoid bp_core_get_root_domain() on each page view for such a constant value?

Generally, I think we'd like to avoid adding constants for this kind of reason. See next question.

Is it possible to use object cache for bp_core_get_root_options()?

I think this is the right thing to do. Invalidation will not be trivial (some of the root options are stored in sitemeta while others are in the root blog's options table), but we can probably abstract some sort of cross-listing of the root_options values and then catch the generic WP options post-save hooks.

bp_update_is_item_admin( bp_user_has_access(), 'core' ) is only neccessary for profiles, is it?

If I understand correctly, this line is setting a default value that gets swapped out by some other components. I think you're correct that the default value is only accessed on user profile pages, which suggests that we could probably refrain from doing the check on non-root sites. But this is the kind of change that could potentially break stuff, so it'll have to be studied more (and ideally, some integration tests will have to be written before changing it)

Let's continue to use this ticket in the 1.8 cycle for locating extraneous switch_to_blog() calls and zappin' 'em.

[boonebgorges]

See #4954

[r-a-y]

In 8188:

In bp_get_option(), check the buddypress()->site_options array first.

This is to prevent having to use get_blog_option() if we have already
fetched the option in question.

See #4913

[boonebgorges]

In 8199:

Don't check buddypress()->site_options in bp_get_option()

This reverts the change in r8188. The check in site_options is intended to
provide a speed benefit, but it causes problems when not mirrored properly
in bp_update_option(). We'll take a closer look at this in a future release.

See #4913

[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/