[fbutera101]

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.

[ri-kun]

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

[deadlyhifi]

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

function custom_bp_adminbar_login_menu() {
global $bp;

if ( is_user_logged_in() )
return false;

$redirecturl = $bp->root_domain . '/wp-login.php?redirect_to=' . urlencode( $bp->root_domain ) . esc_url( $_SERVER );
echo '
' . __( 'Log In', 'buddypress' ) . '

';

// 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.
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.

[tsankuanglee]

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 );
echo '
' . __( 'Log In', 'buddypress' ) . '

';

// Show “Sign Up” link if user registrations are allowed
if ( bp_get_signup_allowed() ) {
echo '
' . __( 'Sign Up', 'buddypress' ) . '

';
}
}
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.