[buddypress-trac] [BuddyPress] #4772: Theme compat: Can't load plugins.php template on subnavs of core nav items (was: Duplicate sub nav 1.7 when using bp_core_new_subnav_item)

[buddypress-trac]

#4772: Theme compat: Can't load plugins.php template on subnavs of core nav items
--------------------------+-----------------------
 Reporter:  modemlooper   |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  1.7
Component:  Core          |     Version:  1.7
 Severity:  critical      |  Resolution:
 Keywords:                |
--------------------------+-----------------------
Changes (by boonebgorges):

 * severity:  minor => critical


Comment:

 OK, this is more serious than it seems at first. The duplicate menu
 modemlooper is annoying but minor. But it's a symptom of a much bigger
 problem.

 Plugins like subnav.php load render their content in the context of
 members/single/plugins.php. When using a non-BP theme,
 `bp_core_load_template( 'members/single/plugins' )` fails to locate a
 template (as it does with all BP templates), and so theme compat kicks in.
 The logic in theme compat works like this:

 1. Load the home.php template
 (`BP_Members_Theme_Compat::single_dummy_content()`), because we're looking
 at a member page.
 2. In members/single/home.php, we do have an `else` condition. But it is
 only hit if you fail all of the previous `if` conditions. When adding a
 subnav item to a core item, one of these `if` conditions will hit. Thus
 the plugin's markup will never load. (In modemlooper's case, it does
 happen to load, because the settings templates work a bit differently. But
 if you switch it so that he's adding to, say, 'friends', youll see that
 his content never renders.)

 It's not a problem in bp-default, because `bp_core_load_template()`
 succeeds in finding plugins.php, and plugins.php contains all of a page's
 markup, including header/footer/sidebar. In bp-legacy, plugins.php has
 been stripped down and loaded within the context of home.php.

 This is a pretty serious problem, as it will break a whole class of
 plugins. The only viable strategy I can think of is something like
 4772.patch. This is very ugly, obviously, and would have to be made
 better, but the basic idea is:
 - In bp_core_load_template(), if no template is located, check to see
 whether the request was for plugins.php
 - If so, set a flag that says "this ought to load plugins.php"
 - In the home.php template, check that flag before doing anything else

 In the absence of a fix, plugins like this will have to filter
 `bp_get_template_part` in order to display their content.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4772#comment:19>
BuddyPress <http://buddypress.org/>
BuddyPress