[buddypress-trac] [BuddyPress] #4913: BP_Core->setup_globals is very expensive on child sites in a network (switch_to_blog())

[buddypress-trac]

#4913: BP_Core->setup_globals is very expensive on child sites in a network
(switch_to_blog())
--------------------------+------------------
 Reporter:  wpdennis      |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  1.8
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------
Changes (by boonebgorges):

 * milestone:  Awaiting Review => 1.8


Comment:

 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.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4913#comment:1>
BuddyPress <http://buddypress.org/>
BuddyPress