[wp-trac] [WordPress Trac] #39123: Allow usernames to be changed by administrators

WordPress Trac noreply at wordpress.org
Tue Dec 6 22:46:21 UTC 2016


#39123: Allow usernames to be changed by administrators
-------------------------------------------------+-------------------------
 Reporter:  johnbillion                          |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Users                                |  Review
 Severity:  normal                               |     Version:
 Keywords:  needs-patch needs-unit-tests 2nd-    |  Resolution:
  opinion                                        |     Focuses:  multisite
-------------------------------------------------+-------------------------

Comment (by johnjamesjacoby):

 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39123#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list