Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 6 years ago

#4913 closed enhancement (maybelater)

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

Reported by: wpdennis's profile wpdennis Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Core Keywords: dev-feedback, trac-tidy-2018
Cc:

Description

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?

Change History (7)

#1 @boonebgorges
11 years ago

  • Milestone changed from Awaiting Review to 1.8

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.

#3 @boonebgorges
11 years ago

  • Milestone changed from 1.8 to Future Release

#4 @r-a-y
10 years ago

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

#5 @boonebgorges
10 years ago

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

#6 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

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/

#7 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.