WordPress.org

Make WordPress Core

Opened 10 years ago

Last modified 10 months ago

#12671 assigned enhancement

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

Reported by: thedotproduct Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9.2
Component: Upgrade/Install Keywords: needs-patch needs-testing
Focuses: Cc:
PR Number:

Description

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.

Change History (12)

#1 @scribu
10 years ago

  • Keywords needs-patch added; installer removed
  • Milestone changed from Unassigned to 3.0

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.

#2 @nacin
10 years ago

  • Milestone changed from 3.0 to Future Release
  • Type changed from defect (bug) to enhancement

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

#3 @westi
9 years ago

  • Cc westi added

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.

#4 @wojtek.szkutnik
9 years ago

  • Keywords gsoc added

#5 @dd32
8 years ago

  • Owner dd32 deleted
  • Status changed from new to assigned

#6 @SergeyBiryukov
7 years ago

Closed #21136 as a duplicate.

#7 @r0uter
6 years ago

  • Cc 01tonythomas@… added

#8 @jwmarshall
6 years ago

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

#9 @chriscct7
4 years ago

  • Keywords needs-testing added; mysql permissions gsoc removed

#10 @danielbachhuber
4 years ago

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.

This ticket was mentioned in Slack in #core by danielbachhuber. View the logs.


4 years ago

#12 @SergeyBiryukov
10 months ago

#45564 was marked as a duplicate.

Note: See TracTickets for help on using tickets.