Fix #12671: Installer page doesn't check if MySQL tables were created successfully

[yashyadav-mo]

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.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @root@MO-LT-0519.localdomain.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

Core Committers: Use this line as a base for the props when committing in SVN:

Props yashyadav247.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.