Cannot create a user without emailing a reset link

[Ipstenu]

Born from the mind of #32428, fully formed and Athenaesque...

When creating a new user on a site, 4.2 had the option to not email the user a password.

That option is no longer there, so an admin cannot create users on the fly. Can this be restored?

It also impacts #33209

I was just testing my plugins against WP4.3, and discovered that while I could previously notify only admins of new user registrations by calling wp_new_user_notification() (with no 2nd parameter), in 4.3 the behavior is changed: now it seems to always notify both admins and users (there is no longer a 2nd parameter that can be left blank to suppress emails to users).
How can I get back the behavior of WP prior to 4.3: send new user notifications to the admin *only*?

We need a filter

[tharsheblows]

I might be completely confused but is this the same? #33358

[Ipstenu]

In part. The filter part is there, but the checkbox option to NOT email is still missing.

[DrewAPicture]

Replying to Ipstenu:

In part. The filter part is there, but the checkbox option to NOT email is still missing.

I hadn't considered it until now, but you have made a great point that I don't think was well-enough considered in removing the "skip email" checkbox from the UI. This is because that option essentially allowed two distinct scenarios at the same time:

1. Allowed you to create a user without sending them an email
2. Allowed you to create a user without sending them an email with a password in it

In removing the option to accomplish #2, we seem to have also removed #1, which I agree should be restored in the UI. Having the ability only to alter the default behavior via a filter seems like a step back in usability.

[tharsheblows]

Oh I see, thank you! Is this what you need? It adds the checkbox etc back in but I'm not sure on the wording.

Also the password re-set emails send with two links in them, the link with the reset key and, below that, a link to the login page. I can see how that could be confusing to some people and they probably won't re-set their password then go back to their email to use that link:

Username: MJ93

To set your password, visit the following address:

http://src.wordpress-develop.dev/wp-login.php?action=rp&key=PffTwhutf8ysw4M&login=MJ93

http://src.wordpress-develop.dev/wp-login.php

Would it be ok to get rid of the plain login link?

[tharsheblows]

adds back in a checkbox to stop new user email

[avcascade]

In removing the option to accomplish #2, we seem to have also removed #1, which I agree should be restored in the UI. Having the ability only to alter the default behavior via a filter seems like a step back in usability.

+1, totally agree. We need to add a checkbox into the UI to prevent an email from being sent. There are going to be times when an admin will want to create a user but not send an email. For example, suppose the new user is a new employee of the admin and is meeting with the admin in person. The new user can choose a password to use at the time of account creation. In that case, there's no need for an email to be sent with a link to regenerate the password.

I tried out the patch. Seemed to work, but two emails got generated on account creation instead of one.

[lisaleague]

This is a real PITA for membership/ecommerce sites when you do group/bulk sales and need to manually add users before creating the transaction.

You don't want people getting passwords for something they don't have access to yet. Or something they don't need to login for at all. This is removing key functionality that many business sites use.

[tharsheblows]

Sorry, I think that the way I did it was unnecessarily confusing, so I've updated the patch to match what was in <4.3.

For the second patch, if the box is checked, an email with a password reset link will be sent to the new user. If it is not checked, no email will be sent. However, the default is now a checked box rather than an unchecked box.

In both cases, a new user notification email will be sent to the admin email address. That doesn't change.

[tharsheblows]

checkbox to send reset link (default checked)

[smerriman]

I'm not sure if this should be a separate ticket or not, but whatever solution is used here should be used identically when editing an already existing user's password or email.

As an admin, I regularly create users on someone else's behalf without wanting to send them an email. I also regularly want to edit such a user's password without notification. This is common during development when you're preparing a website to show a client, on users imported via the WordPress importer, etc.

As it stands such a client will receive an email saying somebody changed their password on a site we're not even ready to show them yet; very confusing for them.

[Ipstenu]

The first part (making users without emailing them) is part of this. The second...

I also regularly want to edit such a user's password without notification.

Why? I ask this sincerely, though I know it always sounds odd. What's the use case there? Right now, WP is generating a random password (good) and requiring a user to get it emailed to them (also good) to get access. Resetting someone's password to a specific password is something we're trying to get away from :)

You can click on the 'lost password' for them (or maybe someone can sort our 'send user a password reset link with a custom message' plugin which would be cool!).

[lisaleague]

@Ipstenu, here's a use case I've had regularly for the 2nd part @smerriman mentioned:

When I add/edit admin users to my site or staging site for support or other services - I don't want this info automatically going out until I'm ready to include it in a ticket.

I'll use the same user for multiple people at a company, who don't necessarily share the same inbox. I don't want it being mailed out automatically so anyone at that mailbox gets it until I'm ready to include with the ticket.

Aside from that - the first case - regularly adding users without an email automatically being sent is a must. I want to continue to be able to add users and not have them receive ANYTHING until AFTER adding transactions or when I decide they need access, not just have it automatically spit out.

[Ipstenu]

regularly adding users without an email automatically being sent is a must

Right. That 100% is what this ticket is about :)

But I don't get the part about the changing password... My assumption, and please tell me if I'm wrong, is you're doing this:

1) Create ONE admin/editor users for a staging site with a 'default' email address (editor@…)
2) Change that password when a new editor is added and an old one is deleted

Is that right?

Is there a reason you're not just making a new user account for each person you're adding to the site? Assuming this ticket is completed (and we can stop emailing new accounts when they're created), you'd just then have to send them the reset link.

[lisaleague]

Actually it does not email a reset link. Upon changing a password WP sends a notification that the password has been changed and does not include a reset link, just a link to the homepage and admin email.

Hi username,

This notice confirms that your password was changed on Site Name.

If you did not change your password, please contact the Site Administrator at
admin@…

This email has been sent to usersemailaddress.com

Regards,
All at Site Name
​http://sitename.com

So the current behavior is not useful to the user whose password you're changing, as it does not include a reset link or link to the login page.

It would make sense to send a reset link, and have a checkbox to turn off sending that email, if the admin does not want it sent.

[Ipstenu]

Actually it does not email a reset link. Upon changing a password WP sends a notification that the password has been changed and does not include a reset link, just a link to the homepage and admin email.

Ah, okay, that's not what I was talking about. I see where you went though! Thank you for explaining.

I don't think, from a security standpoint, it's wise to not alert people to password changes. But it goes back to my question of why, exactly, you are changing passwords for users?

Shared accounts, which is my guess of what you're doing, are complicated and security fraught at best. I would lean towards giving them all a disposable email and using this plugin - ​https://wordpress.org/plugins/allow-multiple-accounts/ - to allow multiple accounts for that email. Then you can change all you want and only the one email is pinged. Plus you have the added benny of now being able to track test users :)

[lisaleague]

I add an admin user (does not matter any temporary user) and give them the credentials. When complete, I change them to no role for this site, but keep the user.

When I need to give them access again, I change their role back to admin or whatever and generate a new password (have been using LastPass, but using WP to generate is fine), BUT I do NOT want an email being sent out automatically and want to control emails going out as I did before.

This was the workflow I was using before and what @smerriman was trying to explain (I think) that they are no longer able to do without an automated email being sent.

There is no security risk in the way I've been handling this.

[tharsheblows]

I am not sure what the right thing is to do, so this isn't a comment on whether it's a good idea to add in a checkbox on the user edit screen.

However, I know there is a filter on the password change emails and the email change emails: https://core.trac.wordpress.org/browser/tags/4.3/src/wp-includes/user.php#L2170

eg
$send_password_change_email = apply_filters( 'send_password_change_email', true, $user, $userdata );

if you add a filter that returns false, the email shouldn't send. You could add in the filter during development and then remove it on the production site if you wanted.

[smerriman]

I mentioned a use-case in my original message - after running the WordPress importer, you're prompted to change the passwords of imported users. You can't do so without notifying all of those users, even if you are using their original password.

I agree this can already be done with filters, but from that perspective, so can the original request.

The reason the emails were sent was "so if someone hijacks your browser session and changes these items, you’ll be notified that it happened, and you can take action."

If the person changing the password has admin rights, this doesn't provide any security benefits or useful information - they already have complete control over the WordPress site, can create new accounts, and delete all other user accounts.

The email received says "If you did not change your password, please contact the Site Administrator". This is misleading when it could well have been the Site Administrator who changed it in the first place.

If these were indeed added for the purpose described above (hijacking your session), then perhaps these emails should only be sent if you change your *own* password (or equivalently, if a non-admin edits it). An admin should have the rights to do whatever they want without needing to resort to editing site code.

[Ipstenu]

The original request is to restore a feature we had that was removed. We used to have a way to add a user without sending email via that checkbox :)

But now we have the following:

• Change user password without emailing
• Send user a 'Your account is activated' kind of email

I think those might be best in their own ticket as I checked on 4.2.4 and you cannot change a user's password without emailing them. So this is not a regression but a new feature. Similar. Most definitely related. Not the same :)

That would kind of be an awesome plugin. You could have one that would 'disable' an account, change it to no-role, and thus no emails would be sent etc. Then you could 'reactivate' the account, which would generate a random password and prompt the user to reset their account.

[smerriman]

Have created #33759 regarding the change of password notifications.

[ahortin]

I believe the redesign of this screen has made things more confusing than they should be. There are numerous use cases, as mentioned by various others here, where you don't want users to be emailed. Creating a new user with a password and then having them also receive an email asking them to reset their password, is extremely confusing. In my opinion there's definitely a need to reinstate the previous checkbox that was on this screen. It should also work as it did previously as well. In other words, only email the user when the checkbox is ticked, as opposed to having to tick a checkbox to NOT email the user.

Simply default the checkbox to being ticked so that people have to specifically untick it if they choose not to email the user. Adding a checkbox back into this screen is one thing, but adding it in and making it work completely opposite of how it used to work, is really confusing things unnecessarily.

Also, the 'Show password' and 'Cancel' buttons are mostly useless. Why not simply show the password field (masked), with a "Show' button next to it. All the "Cancel" button does is hide the password field. It doesn't actually cancel anything. If the new user is saved, it's still created with the auto-generated password. The "Cancel" button is confusing the UI.

Likewise, the 'Show password' button seems useless as well. Why bother hiding the field in the first place? If people are intent on changing the auto-generated password, they're going to do it anyway, no matter whether they have to show the password field first or not. It's adding an extra button to the screen that doesn't need to be there. Simply show the field (along with the strength indicator) and default the password to be masked. As it is at the moment, you can't save the new user details if the password is less than Medium anyway, so that's really good.

[helen]

Had to ship 4.3.1, moving to 4.3.2. Seems to still need a full approach defined, including what would be a MVP bugfix and what can hold for 4.4 if blocking.

[jb510]

I love the fancy new password stuff, but rather than punt how about just reverting to 4.2.x?

For a lot of us this is a major regression and it's been maddeningly frustrating that wasn't fixed quickly. We're now over a month out...

[kevinwhoffman]

I feel like the MVP fix is to address the original ticket's purpose which is to put back the checkbox that emails a user on account creation. The discussion above brings up other issues that cause concern but I don't see why, in the meantime, we can't replace the original checkbox to opt out of new user notification. This has become a major issue in running a membership site where users are often created before we wish to notify them.

[tharsheblows]

Hi - the second patch, 33504.2.diff, adds a box which defaults to checked as @ahortin mentioned. It looks like this:
​https://cloudup.com/cf9V7GVUoeR

Is that about what it should be?

Regarding the password field, that could be a bit more complicated and might be better in a new ticket rather than holding up this one. I think consensus might help this one get committed? I'm not sure but it couldn't hurt. :)

[kevinwhoffman]

Replying to tharsheblows:

Hi - the second patch, 33504.2.diff, adds a box which defaults to checked as @ahortin mentioned. It looks like this:
​https://cloudup.com/cf9V7GVUoeR

Is that about what it should be?

Yes, that looks like the type of MVP fix that would address the original ticket. I agree the password changes after account creation should be treated as a separate ticket if it helps this one to get pushed through faster.

[tharsheblows]

refreshed patch with checkbox checked as default to send email

[tharsheblows]

I refreshed the patch, I should have made sure it worked with the change in wp_new_user_notification (eek sorry, I doubt that will ever happen again though, it's too embarrassing). I think works now and it still looks exactly like this in the admin: ​https://cloudup.com/cf9V7GVUoeR

[bquerry]

Please add the check box back into core. I have a similar workflow and agree with @lisaleague from above:

When I add/edit admin users to my site or staging site for support or other services - I don't want this info automatically going out until I'm ready to include it in a ticket.
I'll use the same user for multiple people at a company, who don't necessarily share the same inbox. I don't want it being mailed out automatically so anyone at that mailbox gets it until I'm ready to include with the ticket.

Aside from that - the first case - regularly adding users without an email automatically being sent is a must. I want to continue to be able to add users and not have them receive ANYTHING until AFTER adding transactions or when I decide they need access, not just have it automatically spit out.

[Ipstenu]

"Send a link to the new user by email so they can choose their own password." is not really accurate.

"Send the new user a reset password link" would be more descriptive. Though that's possibly implicative of other functionality we should have... Still it better reflects what the email is that the user will be getting.

[tharsheblows]

I've changed the wording. However I'm not completely sure about this patch as [34251] by boonebgorges changes things a bit. I've gone ahead and updated all those actions (not just the one needed here) so they're consistent but not sure if that's the right thing to do.

[tharsheblows]

refresh patch and update other actions for consistency

[tharsheblows]

patch against 4.3 branch with updated wording (prev patch was against trunk)

[SergeyBiryukov]

#34472 was marked as a duplicate.

[jobst]

YES, I can second this, it is terrible not to have that option!

Thank you for stating the blatant obvious. I am grumpy as we send about 30 emails the last 5 days without knowing they were getting them, besides the email is really badly formatted as well.

Replying to lisaleague:

This is a real PITA for membership/ecommerce sites when you do group/bulk sales and need to manually add users before creating the transaction.

You don't want people getting passwords for something they don't have access to yet. Or something they don't need to login for at all. This is removing key functionality that many business sites use.

[DrewAPicture]

Replying to jobst:

YES, I can second this, it is terrible not to have that option!

Thank you for stating the blatant obvious. I am grumpy as we send about 30 emails the last 5 days without knowing they were getting them, besides the email is really badly formatted as well.

I recognize that you're frustrated, but a little bit of understanding goes a long way here on Trac. The nature of software development is that sometimes when you fix something, you break something else. It's inevitable.

Reinforcing a point by effectively putting down the work of a lot of people who came before isn't constructive. If the email is badly formatted, let's fix it and move on. If you'd like to help solve the problem, please, test the patch and provide feedback.

[kevinwhoffman]

This is my first time trying to test a patch with SVN, but I want to help. I am trying to test 33504.5.diff from @tharsheblows but I keep getting an error:

Here is the process I followed:

svn co https://develop.svn.wordpress.org/tags/4.3

I then moved the patch to the 4.3 folder.

cd 4.3
patch < 33504.5.diff
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/wp-admin/includes/user.php b/wp-admin/includes/user.php
|index 8e1df4f..bcda72b 100644
|--- a/wp-admin/includes/user.php
|+++ b/wp-admin/includes/user.php
--------------------------

I also tried moving the patch to the /src folder and I get the same error. Please let me know what I'm doing wrong. Thank you.

[johnbillion]

Thanks for helping out, @kevinwhoffman!

Try this command instead. You'll need to run it from the /src subdirectory because the patch was generated from that directory.

patch -p0 -i 33504.5.diff

Alternatively, if you're familiar with Grunt you can use the grunt patch:xxxxx command to automatically fetch and apply patches from a ticket. ​More info here.

[kcrusher]

Just adding my voice to the ones frustrated with the new behavior.

My scenario - I have a client that has a ton of contributors to their site and are adding new ones regularly. The site has a VERY specific look/design and trying to train new authors on how to create a post and use the editor (which has a ton of custom functionality) isn't going to happen. So what they do is create new user accounts for each author and use User Switching to post as that author. Without the option to not send the user an email upon registration, they're currently having to use a 'dummy' email account that they have access to, set up the new user with that account email, reset the password, then go back and edit the user to put in their correct email.

The reason for them needing user accounts in the first place is that each author has an image, their social links, etc. in their user profile and which is used to display in their posts. They can opt to have an email link in their posts for people to email them directly.

Just one of many scenarios where having the ability to suppress the email is a welcome feature.

[kevinwhoffman]

Try this command instead. You'll need to run it from the /src subdirectory because the patch was generated from that directory.

patch -p0 -i 33504.5.diff

I tried this and I'm getting the same error. I am on revision 35465 if that helps. Has anyone else been able to apply the patch successfully?

[tharsheblows]

I am so sorry @kevinwhoffman, that's my fault for not being precise, 33504.5.diff is against the 4.3.1 tag so you'll need to check out ​https://develop.svn.wordpress.org/tags/4.3.1

That patch (33504.5.diff) is for people who would like to test and maybe patch it now with the current version (4.3.1).

33504.4.diff is against trunk and needs someone who knows more than I do to look at it because of [34251] from @boonegorges which moves new user notification emails to add_action() callbacks.

[helen]

There's a lot to process on this ticket - can we get a summary of what patch(es) should be looked at, what it does in prose (i.e. describe the current flow and then the new flow), and any relevant screenshots?

[tharsheblows]

Currently the add new user screen in admin has no way to opt out of sending new users a password reset email. ​https://cloudup.com/id3RbpuvhWT

33504.4.diff adds a checkbox so you can choose to not send the user a password reset email. The checkbox is checked by default to reproduce the ui of <4.3 where a checked box meant send the new user the password by email. ​https://cloudup.com/i-hLJZc0sXF

33504.4.diff is the one to use and is working for me with 4.4-beta4-35625-src although I don't think it's been tested otherwise.

I have a question about it though. [34251] moved all new user notifications to action hooks so I made those all consistent. I don't know if that was the right thing to do. Was it?

[kevinwhoffman]

I second @tharsheblows description of the issue and the proposed solution. I also agree that the question on the use of hooks needs answered so that the solution can be made consistent with the rest of the new user notifications.

[lisaleague]

The checkbox as shown in the in 33504.4.diff will work for me, thanks.

[SergeyBiryukov]

For reference, the new password UI was introduced in [33023].

33504.6.branch.diff​ is a patch for the 4.3 branch, based on 33504.5.diff​ with a couple of changes:

• Replace _e('') and an empty label with a proper heading, like it was in 4.2.
• Uncheck the checkbox by default to restore 4.2 behaviour. Do we want to keep the current behaviour instead?

33504.6.trunk.diff​ is a minimal patch for trunk with the same approach.

Passing $notify to network_*_created_user actions, like in 33504.4.diff​, does not make a lot of sense to me, as the variable does not exist in those functions. If it's something we want to explore, it should be in a new ticket.

33504.send-password.4.2.png​ shows the "Send Password?" checkbox in 4.2.

33504.send-reset-link.4.3.png​ shows the new "Send Reset Link?" checkbox with 33504.6.trunk.diff​ applied.

[tharsheblows]

Uncheck the checkbox by default to restore 4.2 behaviour. Do we want to keep the current behaviour instead?

Yes, I think the checkbox should stay checked as the new default should be to send a user a password reset link rather than setting their password for them. Also it under the password it says that a password reset link will be sent to the new user so it should match that.

People who used that option prior to 4.3 are used to an unchecked box meaning the email won't be sent. There's some discussion of it above.

[ahortin]

Any chance we can please get rid of the 'Show password' and 'Cancel' buttons and instead just show the (masked) password field with a 'Show' button next to it. The only thing those buttons do is show/hide the password field and it confuses the UI unnecessarily.

[jobst]

33504.send-reset-link.4.3.png is confusing: on one had under the button it shows "a password reset link is send to the user" but you also have "Send reset link" checkbox, so what is valid? Does the reset link override the button or vice versa?

I fully understand the need for the reset link, but there are many times when you need to set a password (as admin), hence why 33504.send-password.4.2.png is a good option but instead having a "sent password" have a "send reset link" instead (I agree here with @ahortin.

Explanation for why it is good to have the option to create passwords (and I am sure I cannot be the only one). We sell products/courses in bulk to companies that require their employees to login. Many times we do this together with managers who lead a group of people requiring those logins. Instead of sending lengthy emails to users we do this through the managers who then in turn deal with their team - but we also send the passwords (secured) to the managers to stop endless ping pong email games to the manager's team who cannot understand what the "reset password link" is all about.

With that "show password" button you make my life (and the people who create users in our company) very, very hard.

I, too, get many users (from many parts of life) who try to reset their passwords and fail - one must always think of people who still do not get a lot of stuff online. Giving admins the options of creating a password for users and send that in an email to the users who need a little bit more help is a bloody delight at times!!

[SergeyBiryukov]

Replying to tharsheblows:

Yes, I think the checkbox should stay checked as the new default should be to send a user a password reset link rather than setting their password for them. Also it under the password it says that a password reset link will be sent to the new user so it should match that.

33504.7.branch.diff​ is a patch for the 4.3 branch with the checkbox enabled by default.

33504.7.trunk.diff​ is for current trunk.

Screenshots are the same as in comment:43 :)

Replying to jobst:

I, too, get many users (from many parts of life) who try to reset their passwords and fail - one must always think of people who still do not get a lot of stuff online. Giving admins the options of creating a password for users and send that in an email to the users who need a little bit more help is a bloody delight at times!!

Unfortunately, not emailing passwords in plain text was ​one of the goals for the new UI to improve security (see also the discussion in #24633), so this is probably not going to change.

Sounds like a good idea for a plugin though.

[tharsheblows]

Replying to SergeyBiryukov:

33504.7.trunk.diff​ is for current trunk.

Thank you! I've refreshed it because of [35718] and it's working for me (usual caveats apply). And thanks for explaining about the $notify parameter, I was looking at it the wrong way around. :)

[tharsheblows]

refresh patch as wp-includes/user-functions.php has moved

[SergeyBiryukov]

Restore DocBlock changes in wp-includes/user-functions.php

[ocean90]

In 35742:

Users: Allow to create users without sending an email to the new user.

This adds a checkbox to wp-admin/user-new.php to prevent sending an email with the username and a password reset link to the new user. Restores the behavior of pre-4.3.

Fixes #33504.
Props tharsheblows, SergeyBiryukov, DrewAPicture, ocean90.