[buddypress-trac] [BuddyPress Trac] #5436: BP_Core shouldn't run on 'bp_setup_components'

[buddypress-trac]

#5436: BP_Core shouldn't run on 'bp_setup_components'
-----------------------------------+------------------
 Reporter:  r-a-y                  |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  2.0
Component:  Core                   |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------
Changes (by boonebgorges):

 * keywords:  commit => has-patch 2nd-opinion


Comment:

 Crud, so this is going to be more complex than I'd thought.

 Applying r-a-y's patch causes other problems. Now bp-members is running
 its setup_globals() before bp-xprofile, which means that the call to
 `bp_core_get_user_displayname()` is failing (eventually, it ends up in a
 query to a table name that does not exist)

 I see two different paths we might pursue:

 a. Settle on a component load order that we are happy with, and enforce it
 somehow
 b. Make the necessary changes to prevent components from touching each
 other until they're fully loaded

 Choice a is easier, but b seems better to me.

 I've attached a patch that shows how we can easily do this in the case of
 the logged-in user fullname. Basically: use only WP data when setting up
 bp-members (because we can't be sure that xprofile is active or loaded).
 Then, when xprofile loads, overwrite the WP value (if necessary).

 r-a-y, I know this all stems from my suggestion to use
 `BP_Group_Member_Query` in `BP_Groups_Group::populate()`, and that it
 results in a similar problem (because the current group gets loaded in bp-
 groups::setup_globals(), before the members component is loaded). I think
 we can do something similar there too. There's no need for user
 last_activity data when getting a group's admin mods, so we can just pass
 'populate_extras=false' to `BP_Group_Member_Query` when populating the
 group object. This should prevent entanglement with the members component
 (and it'll prevent a needless query or two).

 There may be other places where this kind of thing happens, and we'd have
 to handle them on a case-by-case basis. But I think this is the sound way
 to approach the problem.

 To be clear, I think that r-a-y's original idea to load bp-core first
 still makes sense, even if we're going to make spot-fixes for individual
 component entanglements.

 What do you think?

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