[lflier]

For removing mentions, this documentation may be useful. It’s for BuddyBoss, which is a fork of BuddyPress, but it looks like it would work:

Try copying this into your functions file: add_filter( ‘bp_activity_do_mentions’, ‘__return_false’ );

bp_activity_do_mentions()

[lflier]

@henrywright

Thanks. I’ll try this as time permits.

In the meantime I can share with @josephfrio13yahoocom what I know about changing the BuddyPress subnav section:

1. You’ve seen a working example of creating a new subnav in the code I posted earlier. Just substitute your own output function for the xprofile_screen_change_avatar function in the line:

add_action( 'bp_template_content', 'xprofile_screen_change_avatar' );

2. To remove a subnav item see my post here.

3. To change the default subnav, which you will have to do if you want to delete a default subnav, see the BuddyPress codex here, which has a nice example.

I’m sure Henry could do better, but I hope this gets you started. All of this can be done in a functions.php file. No modifications of the BP core should be necessary.

[lflier]

Same output as before.

[lflier]

@henrywright

Thanks, Henry. Your suggestion is intuitive and it was my original plan, too. I tried it that way first and failed (same result as above).

Then I went back to the code I had used in my own site, which is the lf_screen_function() that adds an action to the function that gives the desired output, which, in this case appears to be the xprofile_screen_change_avatar function. But that also failed.

There’s got to be a way to do it, though.

[lflier]

@josephfrio13yahoocom you have a fine question. I am one step away from being able to answer it for you. I know how to create and delete subnavs, and I know how to set up screen functions for the subnavs I create. But I am not yet able to connect a new subnav with an existing BuddyPress screen function.

I tried the following code last night, but was unsuccessful:

function setup_custom_nav() {
	global $bp;
	bp_core_new_subnav_item( array(
		'name' => __( 'Change Avatarr', 'buddypress' ),
		'slug' => 'change-avatarr',
		'parent_url' => $bp->loggedin_user->domain . 'settings/',
		'parent_slug' => 'settings',
		'screen_function' => 'lf_screen_function',
		'position' => 30,
	) );
}

add_action( 'bp_setup_nav', 'setup_custom_nav');

function lf_screen_function() {
	add_action( 'bp_template_content', 'xprofile_screen_change_avatar' );
	bp_core_load_template( apply_filters( 'bp_core_template_plugin', 'members/single/plugins' ) );
}

What I get from this is another whole site-generator division inside the already existing one. I get the same thing if I put ‘xprofile_screen_change_avatar’ in directly for the screen function.

I’m getting the screen function from here: https://github.com/buddypress/BuddyPress/blob/12bc8cb1b6000d73be2d43e1c34e26c42b5ff215/src/bp-xprofile/bp-xprofile-loader.php#L216

[lflier]

Thanks Henry,

I was afraid of that…

But here’s a happy thought… Suppose you took the screen function from the subnav in the Profile nav that you want to move to Settings and assigned it to a new subnav item you created in Settings. Then you just remove the subnav from the Profile nav and the effect is just like moving the subnav from Profile to Settings.

Haven’t tried it, but I suspect it would work.

[lflier]

I’d like to know how to do this, too. Some of the subnav items would make more sense for my application if they were grouped differently.

[lflier]

Sorry Modemlooper if I wasn’t clear on what I mean by “home page.” I’m new at this game. What I mean is the page with the URI that starts with root/members/username/… . This is the page that shows the user’s activity, profile, messages, friends, groups, forums, and settings. This is the page that appears to lack the transition effects of the other pages (root/activity) and (root/members).

Thank you Henry for your confirmation of my observations. Common sense tells me to wait for BP 2.0. But curiosity drives me to try to figure this out. I found the following script in buddypress.js (my own application uses the legacy theme):

	/**** Tabs and Filters ****************************************************/

	/* When a navigation tab is clicked - e.g. | All Groups | My Groups | */
	jq('div.item-list-tabs').on( 'click', function(event) {
		if ( jq(this).hasClass('no-ajax') )
			return;

		var targetElem = ( event.target.nodeName == 'SPAN' ) ? event.target.parentNode : event.target;
		var target     = jq( targetElem ).parent();
		if ( 'LI' == target[0].nodeName && !target.hasClass( 'last' ) ) {
			var css_id = target.attr('id').split( '-' );
			var object = css_id[0];

			if ( 'activity' == object )
				return false;

			var scope = css_id[1];
			var filter = jq("#" + object + "-order-select select").val();
			var search_terms = jq("#" + object + "_search").val();

			bp_filter_request( object, filter, scope, 'div.' + object, search_terms, 1, jq.cookie('bp-' + object + '-extras') );

			return false;
		}
	});

The conditional statement that checks whether the division has the “no-ajax” class is apparently meant to catch the nav for what I am calling the home page, which has this class attached to it. Merely commenting out those lines results in a non-functional nav (clicking does nothing), so the decision to treat that page differently in the code is surely not arbitrary. There must be some reason for it. What would it be? That there is no ajax on this page?