Theme compat: Can't load plugins.php template on subnavs of core nav items

[modemlooper]

When you add a subnav to a profile tab it is duplicating the entire subnav. I'm using code below. This code does not duplicate subnav on 1.6.3.

function bp_setup_sub_nav() {
	global $bp;
	
		// Add a nav item for this 
	bp_core_new_subnav_item( array(
		'name' => __( 'Subnav', 'bp-subnav' ),
		'slug' => 'subnav',
		'parent_slug' => $bp->settings->slug,
		'parent_url' => $bp->displayed_user->domain . $bp->settings->slug . '/',
		'screen_function' => 'bp_subnav_settings_menu',
		'position' => 40,
		'user_has_access' => bp_is_my_profile() // Only the logged in user and admin can access this on his/her profile
	) );
}
add_action( 'bp_setup_nav', 'bp_setup_sub_nav');

[modemlooper]

I should add, it's when using theme compat. bp-default does not duplicate subnav

[r-a-y]

modemlooper: I think you're referring to Turtleshell specifically as it uses the newer bp_nav_menu() function. The bug has to do with that.

[modemlooper]

not the new template files, it's the bp-legacy files when you use a different theme than bp-default.

[DJPaul]

How do I recreate this, modemlooper? Put the above into a plugin, run twentytwelve with theme compat., and find the subnav (items) duplicated?

[modemlooper]

you can put it in bp-custom or plugin. run any theme that is not bp-default so it uses theme compat

[modemlooper]

TwentyTwelve theme

[DJPaul]

I cannot recreate this.

[modemlooper]

might have got fixed. I'm waiting on beta to give a strict test before posting 1.7 issues

[DJPaul]

Reopen if you can recreate and provide instructions.

[modemlooper]

This is still not fixed. It only duplicates when subnav has a parent of settings. If you change the example code attached to move the subnav under another parent it doesn't duplicate.

[modemlooper]

simple plugin that creates subnav under settings

[modemlooper]

OK, I remove bp_get_options_nav() from plugin.php and nav is not duplicated.

[modemlooper]

The markup;

	<div class="item-list-tabs no-ajax" id="subnav">
		<ul>
			<?php bp_get_options_nav(); ?>

			<?php do_action( 'bp_member_plugin_options_nav' ); ?>
		</ul>
	</div><!-- .item-list-tabs -->

needs to be removed from plugins.php as it is getting duplicated

[modemlooper]

Well that didn't work right, if you remove bp_get_options_nav() then forum subnav doesn't show for bbPress. The settings page has bp_get_options_nav() call at the top and then on the same page it has bp_get_template_part( 'members/single/plugins' ); that has a call to bp_get_options_nav() as well.

[boonebgorges]

Confirmed. Steps to reproduce:

• Enable a theme other than bp-default (theme compat)
• Activate subnav.php
• As a logged-in user, navigate to your profile > Settings > SubNav
• See the double menu

This does appear only to happen on the settings page, and seems to have something to do with the fact that we're using the settings.php template along with the plugins.php template. I'm looking more into it.

[boonebgorges]

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.

[johnjamesjacoby]

(In [6783]) Theme Compatibility:

• Intro duce bp_is_current_component_core() function, to determine if the current component is an active core component.
• Use above function in plugins.php, to help determine whether or not to display the options navigation.
• Update the root level single-member templates to use switch statements, per the settings components convention.
• Fixes #4772.

[hnla]

Patch corrects typo in /single/blogs.php 'case: 'my-groups' ' to 'case: 'my-sites' '

[hnla]

Corrects typo in blogs.php 'my-groups' to 'my-sites'

[djpaul]

(In [6787]) Fix copypasta in switch statement in /members/single/blogs.php. Fixes #4772 again, props hnla