Installer page doesn't check if MySQL tables were created successfully

[thedotproduct]

When running the web-based setup script - My Mysql user didn't have create permissions so no tables were created but the message (underneath all the MySQL errors) said setup was successful.

I think it would be worth doing a check for no MySQL errors before proclaiming the installation a success.

[scribu]

I think it would be worth doing a check for no MySQL errors before proclaiming the installation a success.

Good idea. I think it should run with $wpdb->show_errors on.

[nacin]

This one came in a little late for 3.0. Patches welcome :)

[westi]

It might also be nice if possible to have a generic "capability" check for the mysql permissions that the db user has.

So that the core code / plugin can check to see if the db user has be granted x or y before it tries to do something.

[SergeyBiryukov]

Closed #21136 as a duplicate.

[jwmarshall]

Ran into this bug today. Very surprised, and disappointed, to see that this thread was opened over 4 years ago.

Screenshot: ​http://i.imgur.com/c1hDW9C.png

[danielbachhuber]

For WP-CLI, I've decided to ​assume any database errors during wp_install() is partial or total installation failure.

dbDelta() returns pretty helpful data for determining whether an installation was successful:

array (
  'wp_users' => 'Created table wp_users',
  'wp_usermeta' => 'Created table wp_usermeta',
  'wp_terms' => 'Created table wp_terms',
  'wp_term_taxonomy' => 'Created table wp_term_taxonomy',
  'wp_term_relationships' => 'Created table wp_term_relationships',
  'wp_commentmeta' => 'Created table wp_commentmeta',
  'wp_comments' => 'Created table wp_comments',
  'wp_links' => 'Created table wp_links',
  'wp_options' => 'Created table wp_options',
  'wp_postmeta' => 'Created table wp_postmeta',
  'wp_posts' => 'Created table wp_posts',
)

It would be nice if we could change the return signature of make_db_current_silent() to return this data, or just call dbDelta() directly in wp_install().

Because MySQL permissions can be restricted for table creation or SELECT, UPDATE, or DELETE statements, I think it would be difficult to write an interpreter for all potential errors.

Couple of options to improve things:

1. Inspect the response value of dbDelta(), and warn the user if any tables weren't created as expected.
2. Inspect $wpdb->last_error after make_db_current_silent(), populate_options(), and populate_roles() are called. It should be empty. If it's not, we can let the user know there were database errors on installation.

I'm not sure how to communicate "there were database errors on installation" to the end user, given they may be incapable of resolving them on their own. However, anything we do is better than the success message we currently show.

[SergeyBiryukov]

#45564 was marked as a duplicate.

[juanmaguitar]

Bug Report

Description

The installer reports a successful setup even when database table creation fails due to insufficient MySQL permissions.

Environment

• WordPress: 6.9
• PHP: 8.3.29
• Server: PHP 8.3.29 Development Server (​http://localhost:8080) started
• Database: mysql 8.0.40(restricted user: no CREATE TABLE privilege)
• Browser: Chrome 143.0.0.0
• OS: macOS
• Theme: n/a (fresh install)
• MU Plugins: None
• Plugins: None

Steps to Reproduce

Pre-requisites for these test instructions

• Docker installed
• PHP CLI (php -v should work)
• A MySQL client (mysql CLI) – optional but handy

Start MySQL (example using Docker):

docker run --name wp-mysql-test \
  -e MYSQL_ROOT_PASSWORD=root \
  -e MYSQL_DATABASE=wp_test \
  -p 3306:3306 \
  -d mysql:8

Connect as root:

mysql -h 127.0.0.1 -P 3306 -u root -p

Create restricted DB user (no CREATE TABLE):

CREATE USER 'wpbroken'@'%' IDENTIFIED BY 'wpbroken';
GRANT SELECT, INSERT, UPDATE, DELETE ON wp_test.* TO 'wpbroken'@'%';
FLUSH PRIVILEGES;

Download and extract WordPress.

curl -LO https://wordpress.org/latest.zip
unzip latest.zip
cd wordpress

Serve locally:

php -S localhost:8080

Navigate to: http://localhost:8080
Use DB credentials:

• Database: wp_test
• User: wpbroken
• Pass: wpbroken
• Host: 127.0.0.1

Complete the installation steps.

Verify database contents:

SHOW TABLES FROM wp_test;

# Installer reports success despite missing tables.

Expected Results

Installer should detect database errors and fail the installation.

Actual Results

A lot of errors are displayed but after the errors a "success" message is displayed.

The errors show that the MySQL user (wpbroken) does not have permission to create tables. As a result, every CREATE TABLE query for WordPress core tables (e.g., wp_users, wp_options, wp_posts, taxonomy and comment tables) fails with “CREATE command denied”. Because those tables were never created, subsequent installer queries that assume they exist (INSERT, SELECT, SHOW FULL COLUMNS, DELETE) fail with “Table … doesn’t exist”, leading to a broken/empty database despite the installer continuing.

But after all those errors the installer displays success message even though no tables are created.

Success!
WordPress has been installed. Thank you, and enjoy!

Core Track Ticket: https://core.trac.wordpress.org/ticket/12671

Problem:

In simple terms, WordPress is saying "installation succeeded" even when it could not create the database tables it needs.

So the installer does this:

It tries to create the core tables like wp_users, wp_options, wp_posts.
MySQL rejects those CREATE TABLE queries because the DB user does not have permission.
WordPress prints a lot of database errors.
But after that, it still shows:
Success! WordPress has been installed. Thank you, and enjoy!

That leaves you with a broken install and an empty or incomplete database.

The misleading success screen is rendered in wp-admin/install.php, while the table creation happens through wp-admin/includes/upgrade.php.

Root Cause:

There are really two connected problems.

1. The schema creation step does not fail loudly enough

wp_install() calls make_db_current_silent() in wp-admin/includes/upgrade.php.

That helper currently just calls dbDelta() and does not check whether the table-creation queries actually worked.

dbDelta() also runs the SQL queries without stopping or returning an actual failure signal when a CREATE TABLE query fails.

So WordPress continues as if setup is still progressing, even though the database schema was never created.

2. The installer success page is shown unconditionally

After wp_install() returns, wp-admin/install.php immediately prints the success page.

It does not verify things like:

whether table creation failed
whether wp_install() returned an error
whether required tables now exist
whether later setup steps failed because the tables were missing
So the current flow is basically:

try install
show DB errors on screen
still print success message
That is why the behavior looks so wrong.

Solution:
The fix should make the installer treat failed table creation as a real installation failure.

Recommended fix
Make the install schema step detectable when it fails. In wp-admin/includes/upgrade.php, the code path used by wp_install() should capture failure from table creation instead of silently ignoring it.

Make wp_install() stop when schema creation fails. If the required tables cannot be created, wp_install() should return a WP_Error or otherwise abort before continuing with:

populate_options()
populate_roles()
user creation
default content setup
Make wp-admin/install.php check the result before showing success. If wp_install() fails, the installer should show a clear error message instead of the success screen.