Opened 3 years ago
Last modified 3 years ago
#13569 new defect (bug)
Odd edge case with shared user tables and custom admin username during install
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | lowest | Milestone: | Future Release |
| Component: | Users | Version: | |
| Severity: | trivial | Keywords: | needs-patch |
| Cc: |
Description
- In install 1, run install.php and use a custom username (NOT called 'admin') and set the e-mail to email@….
- In install 2, before installing, set up shared user tables with install 1. Then run the installer. You won't have the ability to choose usernames (that's expected). Use the *same* email.
- Click "Install." You'll get hit with a WP_Error object.
What's happening? The logic in wp_install() is to do a username_exists() against the username passed to it. If the user exists, it assumes that you're using shared user tables. Problem is, wp_install() is passed 'admin' from install.php (as that's the default, and you don't see the fields when custom user tables are setup), while your user is not called 'admin'. The e-mail address is already being used for another user however, so it is creating 'admin' and is failing on the duplicate e-mail address.
If the email address doesn't match any user, I imagine you'd instead get an 'admin' user in your second install, which you could promptly delete. I see no problem with that, as the alternatives are to pick which user should become an admin.
So, the fix would be to change username_exists() and the logic that follows, and instead match the e-mail address with an existing user, and make that user the new administrator. If no user with that email exists, we create an admin user and they can tough it out.
I do not feel this is a blocker at all. The symptoms I am seeing should be the same in 2.9.2 if you removed the admin user in install 1, then proceeded to share user tables with install 2 before installing.
It'd be nice to at least prevent the fatal error and allow the install to finish, however. I do want to get to it in 3.0 if I can, since we now are allowing custom admin names. That said, setting to 3.1.
Good to know my steps to reproduce were clear enough that I can understand the problem six months later. Lowering priority/severity.