BuddyPress.org

You might try the wpmu forums. Lost of trusty brains there. https://mu.wordpress.org/forums/

Yep. If you disable the back end they won’t be able to change the password. You want to disable it completely? How are people going to write blog posts?

Anyway, the password on signup is more than I have time for now. There is a premium plugin available on wpmudev.org http://premium.wpmudev.org/project/set-password-on-wordpress-mu-blog-creation that does what you want. I don’t know if it works with bp or not.

Phunky, ya that $user param isn’t just a user id. It’s the massive wp user object.

$user->all_about_this_person_and_then_some

burtadsit, i meant to say alternative way. sound right?

You could extend on burtadsit plugin and check the users role/cap first and then redirect them accordingly.

scotm, preferred way? I don’t know about that guy. It’s a solution to a specific problem. I don’t dev preferred solutions to bp. Not my job man.

I’ll see if there is a filter I can use to stop this from happening.

So this is a preferred way to avoid the wp-admin or wp-login page versus the Block Admin plugin, correct? This would mean users, including Admin, would have to login from the front end via the sidebar, for example?

You need to make it an actual executable php file by putting <?php at the top and ?> at the bottom of the file.

You can at your peril. There is a secret open source software credit detection routine built into both products. The license doesn’t explicitly say you have to keep it there. However I’ve heard of horrible things happening if you remove it. Open source programmers are very self centered, introverted and vindictive people.

Danger Will Robinson.

In bbpress, When I Hit the “edit” link would like set the “User Type” of the user to “Administrator”, I get “Sorry, that page was not found” in “buddypress-home” theme.

bbPress: bbpress-1.0-alpha-6

BuddyPress: 1.0b2

Wordpress MU: 2.7

All are releases not SVN

Help…

Howdy. The ’10’ is the priority of the filter (normal) and ‘3’ is the number of arguments the oci_login_redirect() function takes.

https://codex.wordpress.org/Plugin_API#Filters

If you take a look at the apply_filters() call that is in wp-login.php it sends along 3 params. The second param is not so obvious:

isset( $_REQUEST['redirect_to'] ) ? $_REQUEST['redirect_to'] : ''

Read it as:

‘if the redirect_to is set to something then use that as the 2nd param and if it isn’t set then pass along nothing as the 2nd param’.

Just in case we want to do something fancy in the filter that has to do with where the redirection was supposed to go in the first place.

thank you!

Can I ask what the 10, and 3 refer to in the very last line of code?

I am just now learning how to understand code that I am reading, and I think I grasp everything but that part.

Well, here’s an even better idea. Don’t create a file called just anything. Call it bp-custom.php and put it in there. Drop that in /mu-plugins. I looked at the SVN log and as of rev 1012 if that file exists in /mu-plugins it gets run before anything else in bp.

Cool. Thanks Andy!

Now I know how to launch all my little tweaks. The official way.

I found a little filter hook in wp-login.php that seemed just right for this. It is buried in that mass of stuff in that file on line 436 (wpmu 2.7).

$redirect_to = apply_filters('login_redirect', $redirect_to, isset( $_REQUEST['redirect_to'] ) ? $_REQUEST['redirect_to'] : '', $user);

So I built a little plugin that hooks this filter.

function oci_login_redirect($redirect_to, $set_for, $user){

$redirect_to = bp_core_get_userurl($user->ID);

return $redirect_to;

}

add_filter('login_redirect', 'oci_login_redirect', 10, 3);

Create a file with the above code and drop it into /mu-plugins. It sends the user to their profile after logging in. You can send them wherever you want them to go by changing $redirect_to.

There’s no settings in the admin panel but you can change the redirect URL within the plugin file, line 21 if I remember correctly.

Go to /wp-content/mu-plugins/bp-core/bp-core-admin.php and comment out line 73 (My Account sub-menus) as well as 148-151 and 153. I’ve also commented out the “create a blog” call which is on line 165.

You may find it only works on new blogs created after installing Block Admin.

Cheers

I redirect to the same /URL/members.

Thanks for insight. Scot M, where are you redirecting to? I was thinking to http:/yoursite.com/members

@danielfelice this actually is a bug, but not of BP, but rather WPMU and WP. Problem is that users are registering on your server “in the future” or rather from a timezone that your server hasn’t hit yet. Judging by what you said, 5 or 6 timezones ahead of the server time. Since it doesn’t exist yet, WP and WPMU spit that out

Make sense? Not sure of a solution, but I hear through grapevine that Otto, one of the WP mods maybe wrote a plugin that fixes this? Haven’t found it, but might be worth a search in the wordpress.org/support/ forums.

Trent

There are workarounds for this, but the real issue is that this is the intended outcome for normal WP. Since it is the intended result for WP, it gets pulled into WPMU since it is synced off the WP development. Since BP works on WPMU, it gets the same result. See the pattern

That “block admin” plugin works well and if users login from the main site, it doesn’t direct them. Only when they hit wp-login.php will they get redirected to the dashboard. If you are a WPMUDEV.org premium subscriber, they have a plugin that changes this default behavior, so I would imagine there are other solutions out there as well.

I believe Andy is going to address this issue, but in the meantime I’ve found some success using the “Block Admin” plugin. This allows you to set a redirect URL when someone tries to access wp-admin. You also need to comment out a few of the Buddypress admin bar sub-menus to prevent users from accessing the backend.

Works fine for me but I agree it’s an issue that should be addressed.

Cheers