[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.1
Component:  Core              |     Version:
 Severity:  major             |  Resolution:
 Keywords:  has-patch commit  |
------------------------------+------------------
Changes (by boonebgorges):

 * keywords:  has-patch dev-feedback => has-patch commit
 * milestone:  2.2 => 2.1


Comment:

 Replying to [comment:9 r-a-y]:

 > `bp_core_load_template( $whatever_is_here )` is for bp-default themes
 only.
 >
 > When theme compat is triggered, theme compatibility correctly loads up
 `'members/single/home'` on user pages:
 > https://buddypress.trac.wordpress.org/browser/tags/2.0.2/bp-members/bp-
 members-screens.php#L433
 >
 > bp-legacy, then, uses `members/single/plugins.php`, which is used as a
 [https://buddypress.trac.wordpress.org/browser/tags/2.0.2/bp-templates/bp-
 legacy/buddypress/members/single/plugins.php template part].
 >
 > Whereas for bp-default, plugins.php is a
 [https://buddypress.trac.wordpress.org/browser/tags/2.0.2/bp-themes/bp-
 default/members/single/plugins.php full page template].  That's why we
 call `bp_core_load_template( 'members/single/plugins' )`.  In an ideal
 world, bp-default's `'members/single/plugins.php'` would be a template
 part like bp-legacy, then you could use `bp_core_load_template(
 'members/single/home' )` instead of `bp_core_load_template(
 'members/single/plugins' )` in plugins.  However, it is what it is I'm
 afraid.

 I don't dispute this distinction between plugins.php for bp-default and
 bp-legacy. But that's not what I'm referring to when I say that something
 is wrong.

 When you load Test1, here's the chain of events:
 - members/single/home.php
 - members/single/settings.php
 (https://buddypress.trac.wordpress.org/browser/tags/2.0.2/bp-templates/bp-
 legacy/buddypress/members/single/home.php#L51)
 - members/single/plugins.php
 (https://buddypress.trac.wordpress.org/browser/tags/2.0.2/bp-templates/bp-
 legacy/buddypress/members/single/settings.php#L40)

 The `displayed_user_nav()` comes from home.php, `options_nav` comes from
 settings.php, and the tab content comes from plugins.php

 In contrast, when you load Test2, the chain goes like this:
 - members/single/home.php
 - members/single/plugins.php
 (https://buddypress.trac.wordpress.org/browser/tags/2.0.2/bp-templates/bp-
 legacy/buddypress/members/single/home.php#L54)

 `displayed_user_nav()` comes from home.php and `options_nav` comes from
 *plugins.php*.

 As a plugin author, I find this quite counterintuitive. In the case of
 Test1, it seems clear that my intent is to use plugins.php, *not*
 settings.php. Checking against a whitelist of core components is effective
 at making sure that we don't get odd duplicate (or missing) nav items, but
 it doesn't address the underlying illogic.

 All of this points to a deeper problem, which is that it's problematic for
 template routing - the selection of templates based on the current
 URL/component/action - to be happening inside of templates. Templates are
 loaded from the outside in (home.php contains settings.php contains
 plugins.php), and when the routing logic is inside of the templates, by
 the time you get to settings.php it's not possible to say "whoops, this
 actually isn't a settings page". Contrast this with what good WP themes
 do: `get_template_part( 'content', get_post_format() );` is a single line
 that leaves the routing logic out of the template, where it can be
 filtered/modified independent of the template load order. Obviously,
 moving toward this kind of system is a ton of work, but I do think it's at
 the root of the trouble we're currently having.

 For 2.1, I think that 5552.bp_is_current_component_core.patch is better
 than nothing, and it will be fairly easy to roll back in case we decide to
 go a different direction in the future. So let's go with it.

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