[wp-trac] [WordPress Trac] #12671: Installer page doesn't check if MySQL tables were created successfully

[WordPress Trac]

#12671: Installer page doesn't check if MySQL tables were created successfully
---------------------------------------+-----------------------------
 Reporter:  thedotproduct              |       Owner:
     Type:  enhancement                |      Status:  assigned
 Priority:  normal                     |   Milestone:  Future Release
Component:  Upgrade/Install            |     Version:  2.9.2
 Severity:  normal                     |  Resolution:
 Keywords:  needs-patch needs-testing  |     Focuses:
---------------------------------------+-----------------------------

Comment (by danielbachhuber):

 For WP-CLI, I've decided to [https://github.com/wp-cli/wp-cli/pull/2337
 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12671#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform