Changes between Version 1 and Version 2 of Ticket #5436, comment 3
- Timestamp:
- 02/28/2014 07:47:37 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #5436, comment 3
v1 v2 1 1 > 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). 2 2 3 I think 02.patch outlines more of a problem with `bp_core_get_user_displayname()` more than anything even though the patch makes logical sense. 3 ~~I think 02.patch outlines more of a problem with `bp_core_get_user_displayname()` more than anything even though the patch makes logical sense.~~ 4 4 5 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. 5 ~~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.~~ 6 7 '''Edit:''' I'm not fully awake! Me thinks we could also add a parameter so we can run the setup_globals() method based on a custom priority. This would be like the 'adminbar_myaccount_order' parameter in the component `start()` method. Does this sound like too much finagling? 6 8 7 9 > 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.