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

buddypress-trac noreply at wordpress.org
Wed Oct 24 04:13:23 UTC 2012

#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         |  Resolution:
 Keywords:  dev-feedback  |

Comment (by boonebgorges):

 > If you're not on a user profile page, then the BuddyBar? link won't work
 since bp_loggedin_user_domain() isn't passed.

 Groan. In theory, we shouldn't be building the navigation at all on pages
 where it's not going to be displayed, which is to say that it's wasting
 cpu cycles to build `$bp->bp_options_nav` on pages where `! bp_is_user()`.
 (Aside from the Buddybar, of course.)

 What bothers me about using `bp_loggedin_user_id()` is that it will create
 an options_nav that is nonsensical on non-member pages. Eg, when looking
 at the Groups Directory, the `$bp->bp_options_nav` global will contain
 references to the logged-in user's nav. Why is that relevant, aside from
 the Buddybar? It all seems very inelegant and inefficient.

 As much as I would like to rebuild this stuff so that the nav is only
 built when it's actually needed (and then to build a backpat bridge for
 the Buddybar), I can almost guarantee that there are people out there who
 are using the current, peculiar behavior for their own purposes. A total
 refactor, even if it made sense from an architectural point of view, would
 probably break those people's plugins/sites. So, with great sadness, I
 concede that we're probably going to have to go with your solution: first
 try `bp_displayed_user_domain()`, then fall back on
 `bp_loggedin_user_domain()`. (We do this already in, eg, the Activity

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

More information about the buddypress-trac mailing list