[wp-trac] [WordPress Trac] #13569: Odd edge case with shared user tables and custom admin username during install

[WordPress Trac]

#13569: Odd edge case with shared user tables and custom admin username during
install
--------------------------+-------------------------------------------------
 Reporter:  nacin         |       Owner:     
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.1
Component:  Users         |     Version:     
 Severity:  normal        |    Keywords:     
--------------------------+-------------------------------------------------
 1. In install 1, run install.php and use a custom username (NOT called
 'admin') and set the e-mail to email at example.com.

 2. 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.

 3. 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13569>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software