[wp-trac] [WordPress Trac] #17904: Multisite has more restrictions on user login character set
WordPress Trac
noreply at wordpress.org
Mon Mar 13 20:04:18 UTC 2017
#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 flixos90):
@johnjamesjacoby and I had a chat on the behavior of username validation
(and a tiny bit of email validation) in today's bug scrub (see
https://wordpress.slack.com/archives/core-multisite/p1489430014794142).
Here's a summary of what we agreed on:
Functions for username validation:
1. `validate_username()`: Will be modified to accept a second parameter
`$wp_error = false` to make the function return error objects instead of
false. If `is_multisite()`, the function will include the restrictions for
multisite (illegal names, minimum and maximum length, illegal logins, all
numeric).
2. `username_exists()`: In addition for what this function currently does,
it can accept a second parameter `$check_reserved = true`. If that
parameter is true (default), the function also calls
`is_username_reserved()` (see below).
3. `is_username_reserved()`: New method that performs the `wp_signups`
query for existing username that currently happens in
`wpmu_validate_user_signup()`. Returns true/false.
4. `wp_validate_user_login()`: New method that acts as a wrapper calling
`validate_username()`, `username_exists()` with second parameter false and
`is_username_reserved()`. Returns true/WP_Error.
The `$check_reserved = true` parameter of `username_exists()` makes sense
so that by default the check is enforced, but for more granular checking
by calling the functions manually it can be disabled (see
`wp_validate_user_login()` that calls them separately to provide distinct
error messages). This part was not discussed in the chat, but I figured it
would make sense. Correct me if there are concerns with that. :)
On a side note, once we get to a patch and closer to a commit here, we can
open a ticket to perform equivalent changes for email validation.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/17904#comment:64>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list