Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 7 years ago

#4837 closed enhancement (maybelater)

Leaving out the default_subnav_slug param in bp_core_new_nav_item() breaks the new tab display

Reported by: modemlooper's profile modemlooper Owned by:
Milestone: Priority: low
Severity: minor Version: 1.7
Component: Core Keywords: trac-tidy-2018
Cc:

Description (last modified by boonebgorges)

plugins.php needs a face punch!

adding a nav item to user nav with bp_core_new_nav_item adds the item but when you visit the url it shows the members list displaying the users friends. It's not showing the profile header but the members directory.

[Edit - see comment:3 below for more explanation of what's happening]

Change History (6)

#1 @boonebgorges
12 years ago

  • Milestone changed from Awaiting Review to 1.7
  • Priority changed from normal to highest
  • Severity changed from major to blocker

A blocker if true

Can you please take a couple minutes to give us the proper information needed to debug this?

  • The plugin code you're using
  • Trunk rev number you're testing on (svn info)
  • Whether you're using theme compat (I assume you are), and what theme you're using
  • Specific steps to reproduce: what you expect to see, what you actually see

#2 @modemlooper
12 years ago

Somebody posted it in the forum and I tested and sure enough it was showing the members list.

code:

function bp_setup_sub_nav() {
	global $bp;

		// Add a nav item for this
	bp_core_new_nav_item( array(
		'name' => __( 'SubNav', 'bp-subnavy' ),
		'slug' => 'subnav',
		'screen_function' => 'bp_subnav_screen_settings_menu',
		'position' => 40,
		'user_has_access' => bp_is_my_profile()
	) );

}
add_action( 'bp_setup_nav', 'bp_setup_sub_nav' );



function bp_subnav_screen_settings_menu() {

	add_action( 'bp_template_content', 'bp_subnav_screen_settings_content' );
	bp_core_load_template( apply_filters( 'bp_core_template_plugin', 'members/single/plugins' ) );

}


function bp_subnav_screen_settings_content() {

	echo 'Why Roger, why?';

}

EDIT: using the beta.

Twenty Twelve

http://dev.taptappress.com/admin/subnav/

Last edited 12 years ago by modemlooper (previous) (diff)

#3 @boonebgorges
12 years ago

  • Description modified (diff)
  • Milestone changed from 1.7 to Future Release
  • Priority changed from highest to low
  • Severity changed from blocker to minor
  • Summary changed from using bp_core_new_nav_item and plugins.php borked to Leaving out the default_subnav_slug param in bp_core_new_nav_item() breaks the new tab display
  • Type changed from defect (bug) to enhancement

OK, thanks for the additional information.

I've done some investigation, and it turns out that this is not actually related to theme compat at all (or plugins.php for that matter). The problem is that the sample plugin is not using the 'default_subnav_slug' parameter when registering the nav item with bp_core_new_nav_item(). If you do this, it works:

bp_core_new_nav_item( array(
		'name' => __( 'SubNav', 'bp-subnavy' ),
		'slug' => 'subnav',
		'screen_function' => 'bp_subnav_screen_settings_menu',
                'default_subnav_slug' => 'subnav',
		'position' => 40,
		'user_has_access' => bp_is_my_profile()
	) );

This is kind of a quirk in the way that bp_core_new_nav_item() works. (See http://buddypress.trac.wordpress.org/browser/tags/1.6.4/bp-core/bp-core-buddybar.php#L87 to see why.) In the future, it would be nice to refactor this function a bit so that this requirement is not in place - there are other reasons to want to refactor this function anyway.

For now, this is not a regression, and it can easily be avoided by using the default_subnav_slug item. I'll update the ticket title appropriately. Could you please pass this along back the OP on the forums?

#4 @modemlooper
12 years ago

I've never used default slug before, weird its an issue with theme compat. I'll have to update the codex pages.

#5 @DJPaul
7 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#6 @DJPaul
7 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.