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

WordPress Trac noreply at wordpress.org
Wed May 11 02:50:59 UTC 2016


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

Comment (by ericlewis):

 More in attachment:17904.5.diff.

 I've brought over the `validate_username` filter from
 `validate_username()` for backwards compatibility. This filter provides a
 generic true/false way to invalidate a username. If a developer wants to
 add a more explicit `WP_Error` code, they can use the
 `wp_validate_user_login` action. We should deprecate `validate_username()`
 and perhaps have it call `wp_validate_user_login()` directly.

 `wp_validate_user_login()` should stay true to its intent, and exclusively
 handle validation. The function could return true or WP_Error. The
 `wp_validate_user_login` filter shouldn't allow for filtering of the
 user_login, and rather filter the WP_Error, with the `user_login` passed
 in for context.

 `wp_insert_user()` has some duplicate logic. Should we call
 `wp_validate_user_login()` in here? The WP_Error response codes are
 incompatible with the ones merged in from `wpmu_validate_user_signup()`
 (e.g. `user_name` vs. `empty_user_login`).

 I've moved the "is this username pending sign-up?" logic from
 `wpmu_validate_user_signup()` into `wp_validate_user_login()`, which was
 [https://core.trac.wordpress.org/ticket/17904#comment:20 intended
 previously].

 > Oh, I also suggest that we change the username away from admin when
 installing WordPress in unit tests so that some tests can pass.

 I'm going to hold back on this recommendation as it breaks other tests and
 would hamstring our work here. Commenting out the problematic code in the
 unit test for now.

 Other small fixes to get all unit tests passing. All unit tests now pass
 :D

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


More information about the wp-trac mailing list