[buddypress-trac] [BuddyPress Trac] #6534: A new API to manage single items navigation

[buddypress-trac]

#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
 groups).
 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
 *logged-in* user.

 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:

 {{{
 buddypress()->
     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
 `bp_get_loggedin_user_nav()`!!).

 Is this too ambitious? Is it even desirable?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6534#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac