Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#55831 closed defect (bug) (duplicate)

Username restrictions for networks are more stringent than for single-site

Reported by: desmith's profile desmith Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Login and Registration Keywords:
Focuses: multisite Cc:


When you create a new user on a single-site install, the username is run through sanitize_user() which imposes a few restrictions on what the username can look like, what characters can be part of a username, etc.

When you create a new user on a network, the username is run through wpmu_validate_user_signup() which imposes much more strict restrictions on a username. That function runs the username through sanitize_user(), but then also forces the username to be a minimum of four characters long, prevents the username from having a period or @ (so no email addresses as username), prevents the username from being strictly numeric, etc.

While testing out something for a network, I took a site that had several users whose usernames didn't meet those more strict requirements, turned the site to a multisite, and at first glance nothing broke -- the users created before I switched the site to a network, with usernames that violated these restrictions, appear to work just fine, can be assigned roles on sites, can be super-admins, and so on.

Are there reasons I can't see, that users created after a WP install is switched to a network, have more restrictions on their username than users for single-site installs? Is it feasible to make the restrictions for network users' usernames to match those of a single-site?

Change History (2)

#1 @desrosj
2 years ago

  • Component changed from Networks and Sites to Login and Registration
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version changed from 5.9.3 to 3.0

Hi @desmith,

I believe that this is a duplicate of #17904.

If I'm mistaken, please reopen with more details as to why this is unique.

#2 @desmith
2 years ago

Sadly I think you're right. (The "sad" part is because that case has been open for roughly a decade, with no apparent traction on fixing it.)

Note: See TracTickets for help on using tickets.