[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
component.)
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4624#comment:6>
BuddyPress <http://buddypress.org/>
BuddyPress
More information about the buddypress-trac
mailing list