[wp-trac] [WordPress Trac] #17904: Multisite has more restrictions on user login character set

[WordPress Trac]

#17904: Multisite has more restrictions on user login character set
-------------------------------------------------+-------------------------
 Reporter:  duck_                                |       Owner:  jeremyfelt
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
Component:  Login and Registration               |  Release
 Severity:  normal                               |     Version:  3.0
 Keywords:  has-patch has-unit-tests 2nd-        |  Resolution:
  opinion needs-refresh                          |     Focuses:  multisite
-------------------------------------------------+-------------------------

Comment (by jadeweb):

 Seven years, and still active. Yikes! I feel like I may be trying to move
 a mountain by chiming in here, but I'll give it a go anyhow. :)

 I've come to this thread while searching for a way around the strictness
 of multisite username validation. We have setup a multisite install for a
 client's network of ecommerce stores, where the vast bulk of users created
 are WooCommerce customers. Enforcing these restrictions on customers has
 proved to be a terrible experience. I think this is a sensible use-case
 and legitimate UX concern.

 The clear assumption by some in this thread is that these restrictions on
 the username are a hard requirement and usernames created on single-site
 installs should also adhere to them at some point down the road.

 On the contrary though, what strikes me is how torturously contrived the
 restrictions seem to be. The problem boils down to conflating two
 necessary pieces of data in Multisite: a username for the purposes of
 authentication, and a slug for a multisite sub-domain. I agree whole-
 heartedly with @FolioVision's initial position that this is a huge UX
 loss. If the app were refactored to use two pieces of data, the extra
 multisite restrictions would be unnecessary. Whilst setting up a new blog,
 simply offer a slugified version of the username as a default option for
 the subdomain. In so doing, you could:
  - consolidate and simplify username validation logic across single and
 multisite installs, while maintaining backwards compatibility
  - avoid the problem alluded to of having existing usernames become
 invalid
  - existing multisite usernames would continue to work without issue
  - effectively retain the current UX of defaulting to have the domain
 (now, closely) match the user's name
  - allow more human-friendly usernames in all cases

 /end 2¢.

 Cheers,
 David

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