Make WordPress Core

Opened 8 years ago

Last modified 3 months ago

#39123 new enhancement

Allow usernames to be changed by administrators

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Users Keywords: needs-unit-tests 2nd-opinion has-patch
Focuses: multisite Cc:

Description

Usernames cannot be changed. I'd like to propose that users who have the edit_users capability (administrators on single site installations, and super admins on multisite installations) are given the ability to update a user's username from their profile editing screen.

The historical reason for disallowing changes to usernames is not clear, but it's most likely related to the generation of the user_nicename field which ideally needs to remain persistent so author archives don't 404.

However, this can be addressed in the same way as changes to post slugs, where a user's old usernames and nicenames are recorded in usermeta when their username is updated (and their nicename is regenerated) and a canonical redirect can kick in to redirect to the new author archive URL.

Any other considerations to make if usernames are allowed to be changed by administrators?

Attachments (2)

Edit Username WP.png (7.5 KB) - added by lukecavanagh 8 years ago.
Example of editing a username
39123.patch (3.4 KB) - added by neelpatel7295 7 years ago.
Provision for change user name for those particular user who had 'edit_users' caps.

Download all attachments as: .zip

Change History (23)

#1 @johnbillion
8 years ago

  • Focuses multisite added

#2 @mrahmadawais
8 years ago

+1 for this one. This is a huge UX problem, it is very hard to explain that to my clients. They seldom get it and always ask me about why WordPress cannot address any concerns whatsoever. I think this is doable!

#3 @lukecavanagh
8 years ago

@johnbillion

+100 for this, had so many issues for username changes on a live site with 3,000 users. So other them editing that username field in the users record in the DB, was the only option.

#4 @jdgrimes
8 years ago

This would cause issues for any plugin that is storing usernames as a way to identify users rather than IDs. Yes, IDs should generally be used, but the fact that usernames cannot change may mean that some plugins out there are doing it. I can't say I know of any off of the top of my head, though. Unless you count BuddyPress @mentions, though I don't know for sure how those work. Anyway, it would be possible for plugins to match a username up with the correct user by checking the usermeta, I guess, but I thought that this potential back-compat issue was worth mentioning.

#5 @johnbillion
8 years ago

/cc @johnjamesjacoby for BuddyPress.

#6 @johnjamesjacoby
8 years ago

For BuddyPress & bbPress, username mentions in content blocks are problematic in exactly the way you'd expect them to be. They are linked on output, and only on usernames that exist, so old links would not link to new usernames. The human element of a username change is also weird, but in my experience people accept & adapt this change relatively quickly.

I think the main reason this isn't already in core is a lack of a system to handle author archive redirections (similar to redirect_canonical() for single posts.) That, and any unknown third-party integrations. Username changes on WordPress.org, for example, would cause some level of breakage to Trac and Slack. Username changes on WordPress.com would break OpenID integrations. Without a way to redirect requests to old slugs, we can all imagine weird things happening with these integrated systems. Also not sure if any LDAP implementations use the nicename at all.

FWIW, I do agree that certain types of user accounts should be trusted to more easily make these changes within WordPress, both to the user_login and the user_nicename fields. This is probably super/global-admins in multisite, and regular Administrators in single-site. In my imagination, some descriptive text to warn against potential third-party problems is maybe wise, but it should be something that's coy enough to not prohibit the larger percentage of admins from using the feature.

Last edited 8 years ago by johnjamesjacoby (previous) (diff)

#7 @tharsheblows
8 years ago

Any other considerations to make if usernames are allowed to be changed by administrators?

These are slightly random but as I think of them.

  • 99.9% of username changes I do are because someone has used their email address or real name as their username and realised that's not a good idea. (Despite clear warnings. I've tried so hard to make them stop.) In this case, I don't want a canonical redirect from their old author archive to their new one as that's a privacy leak. However, I can see the use in that sometimes, so it'd be great if it were an option.
  • huh, nickname isn't in the REST API.
  • I'm currently forcing nickname (in the usermeta table) to be user_login with no nickname / display_name changes allowed. To do this I hook into the insert_user_meta filter - doing it this way is necessary because of [34505]. I'm mentioning that because I'm not sure how other people do the same thing or if they do. This could be a case where I'm _doing_it_wrong(). I can fix mine to work with whatever if you give me a hook, that's not a problem, but it might be worth seeing how other people handle it and if we need to worry about the nickname field.
Last edited 7 years ago by SergeyBiryukov (previous) (diff)

#8 @lukecavanagh
8 years ago

I just tested this plugin, it works very well on the back-end for easily being able to change the username of a user.

https://github.com/dannyvankooten/change-username

@lukecavanagh
8 years ago

Example of editing a username

#9 @SergeyBiryukov
7 years ago

#41199 was marked as a duplicate.

#11 @swissspidy
7 years ago

Sounds like a duplicate of #14644.

#12 @johnbillion
7 years ago

Agreed, but hopefully the concerns in that ticket can be addressed with:

However, this can be addressed in the same way as changes to post slugs, where a user's old usernames and nicenames are recorded in usermeta when their username is updated (and their nicename is regenerated) and a canonical redirect can kick in to redirect to the new author archive URL.

#13 @raisonon
7 years ago

I suggest extending this to allow the current logged in user to change their own username too.

I'll outline the use case I'm currently coding:

Front end profile settings page. User can amend their first name, last name, email and password from this page.

We are using email as a username, as is standard practice.

In this instance, a user should be able to change their email/username themselves. Currently, this is disallowed.

Ideally using:

wp_update_user()

Hope ok to tag this onto this thread, rather than creating another ticket.

Last edited 7 years ago by raisonon (previous) (diff)

#14 follow-up: @johnbillion
7 years ago

Personally I think allowing users to change their own username is asking for trouble. If an admin changes a user's username, then it's their own site and they can deal with any problems it causes. A user on a site is not in that situation.

#15 in reply to: ↑ 14 ; follow-up: @raisonon
7 years ago

Would it be possible to let wp_update_user() amend username but keep username change limited to Admin in the WP backend?

It's a web standard that login == email, so in that setup we also need to consider how we manage email changes.

I thought most elegant solution is just let email = login and then let the user amend login via a front-facing profile settings page, ideally using wp_update_user()

Do you see a problem with that? Thanks

Replying to johnbillion:

Personally I think allowing users to change their own username is asking for trouble. If an admin changes a user's username, then it's their own site and they can deal with any problems it causes. A user on a site is not in that situation.

#16 @johnjamesjacoby
7 years ago

On the implementation side, I'd prefer to see the who-can-edit-what be settled via map_meta_cap(), via something like current_user_can( 'edit_user_login', $user_id ).

The aforementioned plugin(s) require awkward work-arounds because there is no intercept point for this decision.

  • It's sane to leave this "off by default" because of the slug & author-archive redirection issue.
  • It's sane to allow admins (or multisite super-admins) to measure the risks against the reward and choose whether it's worth it.
  • It's sane to want certain/any/all other users to also have this capability, especially setups where the author slug serves as a vanity feature (BuddyPress, bbPress, etc...)

Using a mapped meta-cap is the way to go here. Whether or not (and to what extent) to update the UI to reflect the new behavior is related but separate discussion IMO.

And we still haven't really addressed the difference between user_login and user_nicename and if nickname is derived from login or whether they are independently editable.

Last edited 7 years ago by johnjamesjacoby (previous) (diff)

#17 in reply to: ↑ 15 ; follow-up: @johnjamesjacoby
7 years ago

Replying to raisonon:

Would it be possible to let wp_update_user() amend username but keep username change limited to Admin in the WP backend?

wp_update_user() calls wp_insert_user() which will happily accept updated user_login and user_nicename values if they exist, regardless of the user's role. They are subjected to things like sanitize_user(), username_exists(), and some filters, but the core functions won't need changing for this specifically.

To make this change role specific, just requires a current_user_can() check in user-edit.php, using a capability that is mapped to edit_users or some other native one.

IMO, allowing all users to edit their own logins and nicenames is not a good idea, because it starts to empower every user with the ability to break other areas of the system (namely author URLs.) I can see admins having exclusive access, but I can also imagine average website owners not understanding the negative impact that losing an author archive of posts is without an adequate redirect strategy.

Tangentially, if we are going to start backing up old slugs for everything (not just posts) then we should build an adequate API to do so, so that taxonomy terms will also benefit, in addition to having something plugins can use (we just needed to rewrite our own approach for BuddyPress Group Slugs in 2.9.0.)

Last edited 7 years ago by johnjamesjacoby (previous) (diff)

#18 in reply to: ↑ 17 @johnbillion
7 years ago

Replying to johnjamesjacoby:

Tangentially, if we are going to start backing up old slugs for everything (not just posts) then we should build an adequate API to do so, so that taxonomy terms will also benefit

Tangentially, see #15953

@neelpatel7295
7 years ago

Provision for change user name for those particular user who had 'edit_users' caps.

#19 @neelpatel7295
7 years ago

  • Keywords has-patch added; needs-patch removed

What i considered into my patch

  • change username (BY those user only who have caps for 'edit_users')
  • user_nickname will be updagted every time when username updated

Missing scope

  • not checked with multisite
  • not maintained the old author slug

Hopefully this can be useful for starting purpose, if anyone looking for better better opportunity to extend this.

Version 0, edited 7 years ago by neelpatel7295 (next)

#20 follow-up: @swissspidy
7 years ago

#42652 was marked as a duplicate.

#21 in reply to: ↑ 20 @rokejulianlockhart
3 months ago

Replying to swissspidy:

#42652 was marked as a duplicate.

Is #14644 a duplicate too? Or, rather, is this a duplicate of it?

Note: See TracTickets for help on using tickets.