WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#27093 closed defect (bug) (fixed)

Cannot install WordPress when a custom user table is defined

Reported by: johnbillion Owned by: johnbillion
Milestone: 3.9 Priority: normal
Severity: major Version: 3.7
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:
PR Number:

Description

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

Attachments (2)

27093.patch (1.7 KB) - added by SergeyBiryukov 6 years ago.
27093.2.patch (1.5 KB) - added by SergeyBiryukov 6 years ago.

Download all attachments as: .zip

Change History (12)

#1 @SergeyBiryukov
6 years ago

  • Milestone changed from Awaiting Review to 3.8.2

#2 @johnbillion
6 years ago

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.

#3 @johnbillion
6 years ago

  • Owner set to johnbillion
  • Status changed from new to assigned

#4 @SergeyBiryukov
6 years ago

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.

#5 @mordauk
6 years ago

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

#6 @mordauk
6 years ago

  • Keywords has-patch added; needs-patch removed

27093.patch worked well for me.

#7 @nacin
6 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#8 follow-up: @nacin
6 years ago

  • Milestone changed from 3.8.2 to 3.9
  • Severity changed from critical to major

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

#9 in reply to: ↑ 8 ; follow-up: @mordauk
6 years ago

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.

#10 in reply to: ↑ 9 @nacin
6 years ago

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.

Note: See TracTickets for help on using tickets.