Opened 2 years ago
Last modified 3 months ago
#17904 new defect (bug)
Multisite has more restrictions on user login character set
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Multisite | Version: | 3.0 |
| Severity: | normal | Keywords: | needs-patch |
| Cc: | d@…, mercijavier@…, pippin@…, chriscct7@… |
Description
Multisite has more restrictions on the characters allowed in a user's login name compared to single site. This seems unnecessary and confusing. It was also the root of a recent bug in the importer, see this forum thread and the workaround.
I haven't worked up a patch yet since there seem to be a few locations where these restrictions are enforced and I don't know if I have found them all yet:
- wpmu_validate_user_signup() uses the regex /[a-z0-9]+/
- ms-default-filters.php adds strtolower to sanitize_user
Relevant: http://mu.trac.wordpress.org/changeset/1689 [12948]
Change History (16)
- Cc d@… added
comment:2
boonebgorges — 18 months ago
- Cc pippin@… added
I'd love to get some more traction on this. It's causing an issue for me with several plugins when running them on MS installs. Here's a bug report for one of the plugins: https://github.com/pippinsplugins/Easy-Digital-Downloads/issues/643
comment:7
follow-up:
↓ 8
SergeyBiryukov — 5 months ago
- Version changed from trunk to 3.0
Replying to SergeyBiryukov:Isn't the version supposed to be the latest version the bug applies to? Or at least that's what I always assumed it was for....
comment:9
SergeyBiryukov — 5 months ago
#23124 was marked as a duplicate.
comment:10
in reply to:
↑ 8
;
follow-up:
↓ 11
SergeyBiryukov — 5 months ago
Replying to chriscct7:
Isn't the version supposed to be the latest version the bug applies to?
Version number indicates when the issue was initially introduced/reported.
comment:11
in reply to:
↑ 10
chriscct7 — 5 months ago
Oh, thats the total opposite of what I thought it was for. Good to know!
Replying to SergeyBiryukov:
Replying to chriscct7:
Isn't the version supposed to be the latest version the bug applies to?
Version number indicates when the issue was initially introduced/reported.
comment:12
SergeyBiryukov — 3 months ago
#23452 was marked as a duplicate.
comment:13
SergeyBiryukov — 3 months ago
Related: #11753
comment:14
Ipstenu — 3 months ago
I was under the understanding that the restrictions are in place because the username is used for the default sitename slug. So to prevent bad URLS, we sanitized everything to match.
If that can be broken out of the username check and only applied to the sitename, that would be okay.
comment:15
boonebgorges — 3 months ago
I was under the understanding that the restrictions are in place because the username is used for the default sitename slug.
Ah, I didn't know that - can you point to documentation of that fact, or are you hypothesizing?
If that can be broken out of the username check and only applied to the sitename, that would be okay.
It'd be straightforward to use, eg, the user_nicename for slugs (that's what it's for, after all). The only potential problem I see with that is that when there are user_nicename clashes (ip@stenu and ipsten@u, for example), they're cleared up with trailing counters (so the second one to get there is ipstenu2, etc). That might be less than ideal from a UX point of view, because URLs would not match usernames. But this is an edge case, and seems to me less important than consistency and flexibility in user_login.
comment:16
Ipstenu — 3 months ago
I swear I read it somewhere, or it was mentioned on IRC, but I can;t find where I saw it. Maybe I got that idea from Otto? (Blame Otto!)
I think the UX loss is more important than mucking with user_login too, though. If there's no other check on sitename validations, we'll have to make sure something's put into place :)
(I swear this came up when someone was kvetching that he couldn't name a site foo.bar for a subfolder site, since that gets wiggy with subdomains.)
See also #BP2207.