[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:  reopened
 Priority:  normal            |   Milestone:  2.4
Component:  Component - Core  |     Version:  1.2
 Severity:  blocker           |  Resolution:
 Keywords:  has-patch commit  |
------------------------------+-----------------------
Changes (by boonebgorges):

 * keywords:  has-patch needs-testing => has-patch commit


Comment:

 Thanks, @dcavins. I've spent a bit of time with your patch, and I think
 it's the right way to go. The `return false` stuff is really goofy, but I
 think that's a price we pay for full backward compatibility.

 The test technique seems OK to me. Ideally, our nav/page registration
 system would have a simple `has_access()` method that we could use for
 unit testing. See #6534.

 A note that the change will result in a very small change in behavior. In
 2.3, registering a navigation item with `show_for_displayed_user=false`
 would fail completely when viewing another user's profile. After this
 change, the nav item will be registered into the global, but it'll never
 be rendered. See `bp_get_displayed_user_nav()`. So if someone is doing
 some weird stuff the globals, they'll see something there that they didn't
 expect to see. I don't really care about these scenarios - and it's
 something I'd like to address in #6534 anyway - but I wanted to put it out
 there.

 Let's go ahead with this for 2.4.

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