[buddypress-trac] [BuddyPress Trac] #6534: A new API to manage single items navigation
noreply at wordpress.org
Fri Jun 26 15:28:47 UTC 2015
#6534: A new API to manage single items navigation
Reporter: imath | Owner:
Type: enhancement | Status: new
Priority: high | Milestone: 2.4
Component: API | Version:
Severity: normal | Resolution:
Keywords: has-patch dev-feedback |
Comment (by boonebgorges):
imath - thanks for getting this started! I think it's a great start and
most of the concepts in the patch seem solid to me.
Regarding r-a-y's suggestion about "ids". I'm not sure if I understand it
correctly, but if I do, then his concern is similar to mine.
We've had a couple of historical problems with our nav system.
1. The distinction between `bp_nav` and `bp_options_nav`, and the
inconsistency in their use between members and non-members (such as
2. Index clashes for nav/subnav items caused by conflicting slugs between
single items (such as a member and a group both called 'foo').
3. The inconsistent context-sensitivity of nav items. When looking at a
group, `bp_options_nav` refers mostly to the displayed content - that is,
the single group. But `bp_nav` is still largely configured relative to the
The technique in 6534.patch goes some way toward fixing this, because navs
are stored in their components - `buddypress()->groups->nav`, etc. I think
we can make the schema a bit more flexible by allowing one more level of
abstraction, by item id/slug. So:
members->nav = array(
4 => array(
'friends' => ...
'groups' => ...
134 => array(
'friends' => ...
'groups' => ...
->groups->nav = array(
54 => array(
'members' => ...
'send-invites' => ....
In other words: index by component, and within each component, support the
building of nav arrays on a per-item basis. (This could also be done like
this: `buddypress()->nav->members = array()`, instead of keeping with the
component. Doesn't matter much.)
In the long run, this would provide perhaps the most flexibility in
building nav arrays. In the short run, for example, imagine you are logged
in as user 4, and are viewing the profile of user 134. Using the schema
above, it'd be possible for nav arrays to be registered both for you and
for the displayed user.
On this scheme, functions like `bp_core_new_nav_item()` would need to
accept additional params for `component` and `item_id`. Defaults would be
based on the currently displayed user.
Backward compatibility with members (`bp_nav`) and groups
(`bp_options_nav[ $group_slug ]`) could work by setting
`buddypress()->bp_nav = new BP_Nav_Backward_Compatibility()` etc, a class
that would implement ArrayAccess and would have `__isset()`, etc methods
that would do the necessary lookups in the new storage locations. In this
way, plugins that directly access `buddypress()->bp_nav` and
`buddypress()->bp_options_nav` would continue to work.
Then something like what imath suggests in 6534.patch could be used as the
primary interface for building and maintaining nav items.
This solves the above problems 1-3. 1 would go away because all items
would be stored in the same component-id schema. 2 would go away because
navs would be split between components, and single items within a
component must have unique IDs or slugs. 3 would go away because we could
build multiple navs in parallel (and we could bring back stuff like
Is this too ambitious? Is it even desirable?
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6534#comment:2>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac