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

Comment (by r-a-y):

 > 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).

 I think 02.patch outlines more of a problem with
 `bp_core_get_user_displayname()` more than anything.

 We should add a filter to bp_core_get_user_displayname() and the xprofile
 component should filter this and add in its fullname when it's enabled.

 > 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.

 Actually, we will need `'populate_extras'` to be true because we will need
 to add in the `is_admin` / `is_mod` flags for each member in the query.
 This isn't being done yet in the
 `BP_Group_Member_Query::populate_group_member_extras()` method, but we
 will need it if we plan on emulating the `$admin_mods` variable in the
 populate() method.

 Don't you love how one thing leads to another? :)

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