[buddypress-trac] [BuddyPress Trac] #5552: bp_is_current_component_core() breaks subnav for plugins that register themselves in component array

[buddypress-trac]

#5552: bp_is_current_component_core() breaks subnav for plugins that register
themselves in component array
------------------------------------+------------------
 Reporter:  boonebgorges            |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  highest                 |   Milestone:  2.2
Component:  Core                    |     Version:
 Severity:  major                   |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------

Comment (by boonebgorges):

 > Somewhere in an older version of BP (haven't looked), it was possible
 for BP to save 3rd-party components into this DB option as well.

 Thanks for the research, r-a-y. I have come to the same conclusion.
 5552-plugins.php demonstrates the problem - it only exists when the
 current component is in the active_components array.

 I'm starting to think that my suggested solution is maybe not the best
 one. But still, I want to try to make the case one more time for a more
 substantial fix, at least for 2.2. Two considerations:

 1. The fact that it's only a problem for existing installations makes it
 less severe, but still pretty severe. Many thousands of installations.
 2. The current setup results in pretty wacky behavior, that avoids
 duplicated menu items only by accident. In 5552-plugins.php, Test1 (subnav
 of Settings) gets its `bp_options_nav()` from settings.php, while Test2
 (subnav of Test2 Parent) gets its `bp_options_nav()` from plugins.php.
 This, despite the fact that plugins.php is used to render the template
 content in each case.

 The more I think about it, the more I think that this is a problem that
 pervades our core template logic. The fact that we are required to load
 plugins.php in settings.php is a sign that something is wrong. Something
 like my original patch should be part of a future version of BP, but it
 should probably accompany a rethink of the way our template structure
 works. All calls to plugins.php should go through a single point in the
 stack, and that is not currently the case.

 So, I guess I'm fine to punt this and do nothing for now, seeing as the
 solutions are almost as ugly as the problem. I can build workarounds into
 Docs and Invite Anyone, and I doubt many others are having the problem at
 the moment.

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