Cannot install WordPress when a custom user table is defined

[johnbillion]

This is a regression in 3.7 caused by r25115.

Steps to reproduce:

1. Install WordPress as normal
2. Prepare a second, separate installation of WordPress by setting up the CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE constants in the wp-config.php file so they point to the first installation's users and usermeta tables respectively (​more info)
3. Run the installation of the second install
4. Note that the installation will abort with the error "Please provide a valid username" even though there is no option to do so

[johnbillion]

It looks like there is also a bug in all previous versions whereby you couldn't install a new site with a shared user table if there was no existing user with username admin because the fallback (which was removed in r25115) is passed right through to wp_install() and affects the logic there. Haven't actually tried it yet.

[SergeyBiryukov]

Before [25115], when installing with a custom user table, we were still forcing the 'admin' username (see [13134]). However, the original intention, per ticket:10396:5, was to only create the user if there are no other administrators in the database.

I guess we should either allow to select a username even with a custom user table, or detect the current administrator's username and use that.

27093.patch​ is an attempt at always allowing to select a username. It throws errors if you enter an email of an existing user, but with a different username, so it needs more work if we want to go in that direction.

27093.2.patch​ implements autodetection of the current administrator's username instead of a hard-coded fallback.

[mordauk]

Just noting that I've just run into this problem as well.

[mordauk]

27093.patch worked well for me.

[nacin]

In 27822:

Install: Allow an installation to go through with a custom user table with the username 'admin'.

This could be better, but this solves the regression caused by [25115].

fixes #27093, see #24078.

[nacin]

[27822] fixes this for 3.9. I wouldn't call this critical simply because an installation with a pre-existing user table is rare and implies detailed knowledge of the underbelly of WordPress, and the workaround is easy enough.

Let's make a new ticket to implement this the "right" way, whatever that may be.

[mordauk]

Replying to nacin:

[27822] fixes this for 3.9. I wouldn't call this critical simply because an installation with a pre-existing user table is rare and implies detailed knowledge of the underbelly of WordPress, and the workaround is easy enough.

Let's make a new ticket to implement this the "right" way, whatever that may be.

I'd disagree about that being uncommon. In the scenario where I ran into this I was setting up a new site that was based off of the user's database of an existing, 5 year old site.

To me, that seems like a very common scenario when setting up sites with shared user tables.

[nacin]

Replying to mordauk:

To me, that seems like a very common scenario when setting up sites with shared user tables.

Absolutely! My larger point was only that, in the grand scheme of things, shared user tables themselves are extremely uncommon. Regardless, [27822] restores previous behavior; a new ticket could make this better in the form of an enhancement.