DB Repair on Multisite looks for wp_1_....

[Ipstenu]

Log in to your site and need to repair. WP nicely prompts you, so you click the repair button and get this:

wp_1_posts: Table 'wordpress.wp_1_posts' doesn't exist
wp_1_comments: Table 'wordpress.wp_1_comments' doesn't exist
wp_1_links: Table 'wordpress.wp_1_links' doesn't exist
wp_1_options: Table 'wordpress.wp_1_options' doesn't exist
wp_1_postmeta: Table 'wordpress.wp_1_postmeta' doesn't exist
wp_1_terms: Table 'wordpress.wp_1_terms' doesn't exist
wp_1_term_taxonomy: Table 'wordpress.wp_1_term_taxonomy' doesn't exist
wp_1_term_relationships: Table 'wordpress.wp_1_term_relationships' doesn't exist
wp_1_commentmeta: Table 'wordpress.wp_1_commentmeta' doesn't exist

I've seen this over and over again, and generally I tell people to go into phpMyAdmin and repair there, which works. But clearly looking for wp_1_ is going to be problematic for non-WPMU upgraded sites. Which are quickly becoming the majority.

Can't reproduce on a clean 3.4 Multisite install.

I can only get those errors if define('MULTISITE', true); is missing in wp-config.php.

I can only get it to repeat if that's true too, which implies it was written in mind of the old WPMU folks (and yeah, a lot of silly people remove that). Isn't there another check we could run, something the user can't screw up so easily, to see if it's old MU or new Multisite?

Can reproduce in trunk by removing define( 'MULTISITE', true );. Offending line of code is ​http://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L730

Suggesting that we close this ticket. Switching to multisite has a pretty clear path, and it includes setting this constant. Not sure that it's worth a big workaround.

Yeah, I'm thinking this should be wontfix in the long run. It's a case of people not following directions. I do wish the error was clearer.