Opened 8 years ago
Last modified 5 months ago
#39123 new enhancement
Allow usernames to be changed by administrators
Reported by: | 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)
Change History (23)
#3
@
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
@
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.
#6
@
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 reason is not having a system in place to handle author archive redirections similar to redirect_canonical()
. 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.
#7
@
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 beuser_login
with nonickname
/display_name
changes allowed. To do this I hook into theinsert_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.
#8
@
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.
#12
@
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
@
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.
#14
follow-up:
↓ 15
@
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:
↓ 17
@
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
@
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.
#17
in reply to:
↑ 15
;
follow-up:
↓ 18
@
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.)
#18
in reply to:
↑ 17
@
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
#19
@
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 opportunity to extend this.
+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!