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 | Owned by: | 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)
Change History (23)
#2
in reply to:
↑ 1
@
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 ?
#3
@
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
@
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.
#5
follow-up:
↓ 6
@
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
@
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:
↓ 9
@
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.
#9
in reply to:
↑ 7
@
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.
#10
follow-up:
↓ 11
@
10 years ago
Not sure why you've a function_exists
check around get_current_screen
.
#11
in reply to:
↑ 10
@
10 years ago
Replying to DJPaul:
Not sure why you've a
function_exists
check aroundget_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
#13
in reply to:
↑ 12
@
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
#14
@
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
@
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
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:
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.