[buddypress-trac] [BuddyPress] #4624: Component subnav items should use displayed user domain, not loggedin user

[buddypress-trac]

#4624: Component subnav items should use displayed user domain, not loggedin user
--------------------------+--------------------------
 Reporter:  boonebgorges  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  high          |  Milestone:  1.6.2
Component:  Core          |    Version:
 Severity:  major         |   Keywords:  dev-feedback
--------------------------+--------------------------
 Several components set up their subnav using `bp_loggedin_user_domain()`.
 See, for example, how Groups does it:
 https://buddypress.trac.wordpress.org/browser/trunk/bp-groups/bp-groups-
 loader.php Line 354 sets `$parent_link` based on the logged-in user's
 domain, and that loggedin user's domain is then used to create links.

 This is pretty obviously wrong. We should be using the *displayed* user's
 domain to create these subnav items, since they should be relative to the
 currently viewed user. Moreover, at the moment, if you're not logged in,
 `bp_loggedin_user_domain()` returns an empty string, which means that the
 subnav hrefs become relative links (sorta by accident), which don't always
 work as expected.

 The reason why this rather big bug has never come up in the past is that
 the components in question (Groups, Friends, Profile) only have a single
 subnav item when viewing another user's profile, and bp-default hides
 these subnavs. See, eg,
 https://buddypress.trac.wordpress.org/browser/trunk/bp-themes/bp-
 default/members/single/groups.php#L14. However, the problem becomes
 evident when calling `bp_get_options_nav()` manually in your own theme.

 I'm happy to go ahead and fix this, but first I want to get a sanity check
 from another dev that changing to `bp_displayed_user_domain()` is indeed
 the right thing to do.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4624>
BuddyPress <http://buddypress.org/>
BuddyPress