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.

[SergeyBiryukov]

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.

[Ipstenu]

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?

[jeremyfelt]

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.

[Ipstenu]

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.