Skip to:
Content

BuddyPress.org

Opened 10 years ago

Closed 10 years ago

#5789 closed defect (bug) (fixed)

Buddypress doesn't send password when admin register new user on MU

Reported by: godavid33's profile godavid33 Owned by: imath's profile imath
Milestone: 2.1 Priority: normal
Severity: normal Version: 1.2
Component: Core Keywords: has-patch commit
Cc:

Description

WP MU 3.9.1
BP 2.0.2

When creating a new user on WP MU from the admin interface, there is no option for a password and WP generates a random password. The user is asked to activate his account and is told "Thank you for activating"; with BP disabled, it is a thank you message and has the randomly generated password shown. The user is sent a verification email with username and "password: [User Set]". At no point in the registration is the user ever shown his password.

Would be useful if on MU or if registered through admin, user is shown random pw on thank you screen and if it were emailed to the user as well. IMO it's a bug if the password is never shown to the user.

Hopefully this isnt a duplicate, I've seen some things similar on other forums and one other ticket that seemed to briefly touch on this I didn't see a solution, fix, or mention other than manually dealing with it, which is not a suitable solution for all purposes.

Attachments (4)

5789.patch (612 bytes) - added by imath 10 years ago.
5789.02.patch (2.1 KB) - added by r-a-y 10 years ago.
5789.03.patch (2.2 KB) - added by imath 10 years ago.
5789.04.patch (2.9 KB) - added by imath 10 years ago.

Download all attachments as: .zip

Change History (23)

#1 follow-up: @godavid33
10 years ago

And it's actually a super easy fix. I unfortunately don't understand how to create a patch, but if in /bp-core-filters.php you change line 261 such that:

line 261:
- return str_replace( 'PASSWORD', __( '[User Set]', 'buddypress' ), $welcome_email );
+ return str_replace( 'PASSWORD', __( $password, 'buddypress' ), $welcome_email );


line 263:
- add_filter( 'update_welcome_user_email', 'bp_core_filter_user_welcome_email' );
+ add_filter( 'update_welcome_user_email', 'bp_core_filter_user_welcome_email', 10, 4 );

Everything works hunky dory (though would also be nice if that post-activation page made a mention to check your email but that's probably customizable with filters since Buddypress is so awesome :] ). As an additional note, might be useful to check to make sure it's multi-site and/or to test this on single site. Not sure if it would change anything there.

#2 in reply to: ↑ 1 @imath
10 years ago

  • Keywords has-patch reporter-feedback added

Replying to godavid33:

And it's actually a super easy fix. I unfortunately don't understand how to create a patch, but if in /bp-core-filters.php you change line 261 such that:

Hi godavid33,

Thanks for your feedback. I'm not sure the fix is that "super easy" :) If the user registers from front end using the BuddyPress registration page, the WordPress generated password (on account activation) is replaced by BuddyPress to the one the user set before activation. The problem is that the user set password is hashed on registration. That's the reason you have the filter on 'update_welcome_user_email'.

In other words, the password generated by WordPress on account activation is not the one the user set when registering.

If you look at the beginning of the bp_core_filter_user_welcome_email(), you'll see that it returns the original welcome email if is_admin(), meaning if the user has been created from the administration.

So i think the problem is due to the fact you're creating a user from the Network Administration user screen. I'm attaching 5789.patch to this ticket, could you check if it solves the trouble ?

Last edited 10 years ago by imath (previous) (diff)

@imath
10 years ago

#3 @godavid33
10 years ago

Ah, but my friend, I am actually only creating them from the subsite admin interface :)

So you're saying the password passed to 'update_welcome_user_email' is already hashed if the user signed up from the front-end?

I will test out a couple things, including your patch, either tonight or tomorrow.

#4 @imath
10 years ago

No i'm saying the password generated by WordPress and passed in the filter is not the one the user set when he registered. When a user registers from front end the password is hashed before being saved in the metas of the signup table.

See : https://buddypress.trac.wordpress.org/browser/trunk/src/bp-members/bp-members-screens.php#L182

Thanks for the test you'll do.

Last edited 10 years ago by imath (previous) (diff)

@r-a-y
10 years ago

#5 follow-up: @r-a-y
10 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 2.1
  • Version set to 1.2

Confirmed.

When an admin is creating a user from the admin dashboard, we shouldn't modify WP's emails.

BP modifies the initial email sent to a user asking them to activate their account and also the welcome email once the user has activated their account.

Surprised no one has caught this bug until now! Nice work, godavid33.

02.patch should address these issues.

Moving to 2.1.

#6 in reply to: ↑ 5 @imath
10 years ago

Replying to r-a-y:

Confirmed.

02.patch should address these issues.

Moving to 2.1.

Thanks r-a-y, i'm wondering (not sure), since it's possible to manage signup from the admin, if the is_admin() check in the function bp_core_activation_signup_user_notification() would have an impact on an admin action (resend or activate)

#7 follow-up: @r-a-y
10 years ago

Good call, imath.

Instead of using is_admin(), we can probably check to see if an admin is explicitly on the "Users > Add New" page in bp_core_activation_signup_user_notification().

When I get a moment, I'll repatch and do some testing with the "Manage Signups" page.

#8 @godavid33
10 years ago

Glad I could help :D

<3 BP

#9 in reply to: ↑ 7 @imath
10 years ago

Replying to r-a-y:

Good call, imath.

Thanks r-a-y, made some tests today. In 5789.03.patch, i'm trying to make sure WordPress is the only one to do the job if user has been created from the "user-new" (admin or network admin) screen.

If for instance the admin didn't choose to skip confirmation and tries to resend the activation email from BuddyPress signups management page, then i also use the built WordPress notification, so that the activation url is wp-acticate.php and once the user clicked on it, then he receives a second email with the password generated by WordPress.

@imath
10 years ago

#10 follow-up: @DJPaul
10 years ago

Not sure why you've a function_exists check around get_current_screen.

#11 in reply to: ↑ 10 @imath
10 years ago

Replying to DJPaul:

Not sure why you've a function_exists check around get_current_screen.

Because if get_current_screen() is not used in an admin screen you get :
Fatal error: Call to undefined function get_current_screen()

And i think bp_core_activation_signup_user_notification can happen while the user is signing up from front end

#12 follow-up: @DJPaul
10 years ago

Couldn't you use is_admin() there?

#13 in reply to: ↑ 12 @imath
10 years ago

Replying to DJPaul:

Couldn't you use is_admin() there?

i think you're right :)

It made me test the patch again. And i've noticed there was a last trouble in case the account was activated from the BuddyPress signups management screen. It was sending a WordPress generated password instead of [user set].

I think it's now ok with 5789.04.patch

@imath
10 years ago

#14 @godavid33
10 years ago

I just tested that last patch and the email sent to the user still had password: [User Set] for me :/

and after updating to the newest BP (2.0.2) and then re-applying my patch, that no longer works either

#15 @godavid33
10 years ago

Oh, I had left a part out of it is why!

line 250:
-function bp_core_filter_user_welcome_email( $welcome_email ) {
+function bp_core_filter_user_welcome_email( $welcome_email, $user_id, $password, $meta ) {

line 261:
- return str_replace( 'PASSWORD', __( '[User Set]', 'buddypress' ), $welcome_email );
+ return str_replace( 'PASSWORD', __( $password, 'buddypress' ), $welcome_email );


line 263:
- add_filter( 'update_welcome_user_email', 'bp_core_filter_user_welcome_email' );
+ add_filter( 'update_welcome_user_email', 'bp_core_filter_user_welcome_email', 10, 4 );

now it's working again

#16 @r-a-y
10 years ago

imath, I think 04.patch is good!

#17 @DJPaul
10 years ago

Yep, looks good to me, too.

#18 @imath
10 years ago

  • Keywords commit added

Thanks r-a-y and DJPaul for your feedbacks, i'm going to commit it.

#19 @imath
10 years ago

  • Owner set to imath
  • Resolution set to fixed
  • Status changed from new to closed

In 8922:

Do not interfere with WordPress sign-up process when the user is created from the blog or the network administration.

On multisite config, make sure the activation email and the welcome email generated by WordPress are not modified by BuddyPress if the user was created from the User Administration panel. In this case, user needs to receive the built in activation link and/or the login and password generated by WordPress.

Props godavid33, r-a-y

Fixes #5789

Note: See TracTickets for help on using tickets.