[buddypress-trac] [BuddyPress Trac] #6503: Separate functions for creating a new nav link and registering a screen function.

[buddypress-trac]

#6503: Separate functions for creating a new nav link and registering a screen
function.
------------------------------+-----------------------------
 Reporter:  dcavins           |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Future Release
Component:  Component - Core  |     Version:  2.3.1
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |
------------------------------+-----------------------------

Comment (by boonebgorges):

 > In doing so, I also needed to move the wp_parse_args() call back out to
 the wrapper function. In order to avoid parsing the args again, I removed
 the wp_parse_args() calls in the new helper functions, but this means that
 they can't be used directly.

 Ah. It's a bit annoying, but I'd say that we should parse the args twice.
 In `bp_core_new_nav_item()`, be sure to stick with the unfilterable
 `wp_parse_args()`. If we decide to introduce `bp_parse_args()` to this
 stack, it'll be in the more specific functions.

 > Do we ultimately want to use the new functions directly?

 I'd suggest introducing new hooks at the end of
 `bp_core_create_nav_link()` and `bp_core_register_nav_screen_function()`,
 and then making a note in the docs for `'bp_core_new_nav_item'` that the
 more specific hooks should be used, because the wrapper may not always be
 used. In BP, we should feel free to call the `bp_core_new_nav_item()`
 wrapper function, but we should avoid using the 'bp_core_new_nav_item'
 hook, unless we want to fire a callback specifically when screen functions
 + nav items have been registered as a package deal.

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