BuddyPress

Hi. I looked for this problem all over the place but can’t seem to find anybody finding an issue with it. Basically, when you’re browsing a blog site on the wordpress MU install, the buddypress admin bar has a redirect_to that sends the user to the main site instead of back to the blog they’re looking at. I think this is rather silly so I went into the admin bar code and saw that it is obviously the intention of the developers to do this. Now, I changed the code myself in the bp-core-adminbar.php and put the redirect to be get_bloginfo(‘url’) instead, which obviously did the trick, but I’m wondering if there’s a way I can change that without a hard code change. If I upgrade at some point, I’ll have to remember to do that every time. Is there a way I can change it so I don’t have to worry about it later on when I upgrade? Is there a filter hook I can use? Thanks in advance.

im experiencing the same issue too. Instead of going to blogs in redirects to the mainpage.

I’ve just experienced this and have come up with a fix:


function custom_bp_adminbar_login_menu() {
global $bp;

// Show "Sign Up" link if user registrations are allowed
if ( bp_get_signup_allowed() ) {
echo '' . __( 'Sign Up', 'buddypress' ) . '';
}
}
remove_action( 'bp_adminbar_menus', 'bp_adminbar_login_menu', 2 );
add_action( 'bp_adminbar_menus', 'custom_bp_adminbar_login_menu', 2 );


Drop that into your functions.php file.

It’s the same as the standard function except it appends the $bp->root_domain with $_SERVER['REQUEST_URI'].
I’m not sure if this is a feature or something that’s been overlooked and needs reporting in trac. Also on different servers I’ve had differing results with php $_SERVER based stuff so I’m not sure if it will work everywhere. It works on the server I’m using anyway.

EDIT: wonky code formatting, try it in pastebin: http://pastebin.com/C96qY2uQ

Wonderful, Tom. A minor tweak to your solution:

The original remove_action may not always work
remove_action( ‘bp_adminbar_menus’, ‘bp_adminbar_login_menu’, 2 );
since we can’t guarantee that buddypress plugin is parsed before this fix plugin. A slight modification I made works for me:

I change
add_action( ‘bp_adminbar_menus’, ‘custom_bp_adminbar_login_menu’, 2 );
to
add_action( ‘bp_adminbar_menus’, ‘custom_bp_adminbar_login_menu’, 1 );
so it will run before the original bp_adminbar_login_menu runs, but after the plugins are parsed and hooks are registered, and then in custom_bp_adminbar_login_menu, I added
remove_action( ‘bp_adminbar_menus’, ‘bp_adminbar_login_menu’, 2 );

Therefore, the whole thing looks like:

function custom_bp_adminbar_login_menu() {
	global $bp;

	remove_action( 'bp_adminbar_menus', 'bp_adminbar_login_menu', 2 );

	if ( is_user_logged_in() )
		return false;

		$redirecturl = $bp->root_domain . '/wp-login.php?redirect_to=' . urlencode( $bp->root_domain ) . esc_url( $_SERVER['REQUEST_URI'] );
		echo '<li class="bp-login no-arrow"><a href="' . $redirecturl . '">' . __( 'Log In', 'buddypress' ) . '</a></li>';

	// Show "Sign Up" link if user registrations are allowed
	if ( bp_get_signup_allowed() ) {
		echo '<li class="bp-signup no-arrow"><a href="' . bp_get_signup_page(false) . '">' . __( 'Sign Up', 'buddypress' ) . '</a></li>';
	}
}
add_action( 'bp_adminbar_menus', 'custom_bp_adminbar_login_menu', 1 );

I agree with fbutera101, though — I am having a hard time imagining a use case where users want to leave where they already are after logging in.