[buddypress-trac] [BuddyPress Trac] #5103: Group slug and user's subnav parent_slug trouble

[buddypress-trac]

#5103: Group slug and user's subnav parent_slug trouble
---------------------------------------+-----------------------------
 Reporter:  imath                      |       Owner:  boonebgorges
     Type:  defect (bug)               |      Status:  closed
 Priority:  low                        |   Milestone:  Future Release
Component:  Component - Core           |     Version:
 Severity:  normal                     |  Resolution:  fixed
 Keywords:  needs-patch needs-refresh  |
---------------------------------------+-----------------------------
Changes (by boonebgorges):

 * owner:   => boonebgorges
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"10745"]:
 {{{
 #!CommitTicketReference repository="" revision="10745"
 Introduce new API for BuddyPress navigation.

 The new `BP_Core_Nav` overhauls the way that BuddyPress registers, stores,
 and
 renders navigation items. Navigations are now component-specific,
 eliminating
 the potential for confusion and conflict between navigation items with
 similar
 names in different components, and opening the possibility of generating
 navs
 for separate objects of the same type on a single pageload.

 The new nav API replaces the old `bp_nav` and `bp_options_nav` system,
 which
 dates from the earliest days of BuddyPress. These global properties were
 responsible for handling nav and subnav across all of BP's components. The
 data
 structure of `bp_nav` and `bp_options_nav` was simultaneously too opaque
 (in the
 sense of being difficult to approach for developers and not having a
 complete
 interface for programmatic modification) and too transparent (forcing devs
 to
 manipulate the global arrays directly in order to customize navigation).
 The
 new system eliminates most of these problems, by removing direct access to
 the
 underlying navigation data, while providing a full-fledged API for
 accessing
 and modifying that data.

 An abstraction layer provides backward compatibility for most legacy uses
 of
 `bp_nav` and `bp_options_nav`. Plugins that read data from the globals,
 modify
 the data (eg `$bp->bp_nav['foo']['name'] = 'Bar'`), and unset nav items
 via
 `bp_nav` and `bp_options_nav` should all continue to work as before.
 Anyone
 accessing the globals in this way will see a `_doing_it_wrong()` notice.
 This
 backward compatibility layer requires SPL (Standard PHP Library), which
 means
 that it will not be enabled on certain configurations running PHP 5.2.x.
 (SPL
 cannot be disabled in PHP 5.3+, and is on by default for earlier
 versions.)

 The new system breaks backward compatibility in a number of small ways.
 Our
 research suggests that these breaks will affect very few customizations,
 but
 we list them here for posterity:

 * Some array functions, such as `sort()`, will no longer work to modify
 the nav globals.
 * Subnav items added to nonexistent parents can no longer be successfully
 registered. Previously, they could be loaded into the global, but were
 never displayed on the front end.
 * Manual management of group navigation items previously worked by passing
 the group slug as the `parent_slug` parameter to the
 `bp_core_*_subnav_item()` functions. The new API requires specifying a
 `$component` ('members', 'groups') when accessing nav items. To provide
 compatibility with legacy use - where `$component` was not required - we
 make some educated guesses about whether a nav item is "meant" to be
 attached to a group. This could result in unpredictable behavior in cases
 where a group slug clashes with a Members navigation item. This has always
 been broken - see #5103 - but may break in different ways after this
 changeset.

 Props imath, boonebgorges, r-a-y.
 Fixes #5103. Fixes #6534.
 }}}

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