I found that renaming all of the tables listed above fixes the issue. However shouldn’t WordPress do this on its own?
I imagine your prefix is hp_.
In WordPress MU, the first blog would have been installed at hp_1, the second blog at hp_2, etc.
In WordPress 3.0 multisite — when not updating from MU — the first blog is instead at hp_, and the second blog at hp_2. This is actually the single fundamental architectural difference between 3.0 and MU.
So, if this is a new multisite installation, then you will have added define('MULTISITE', true); to wp-config.php, which will trigger the new version — i.e. hp_, hp_2. Only if you omitted MULTISITE but WordPress still detected a network would you have issues with hp_1.
How would that occur? Well, the MULTISITE constant is only for 3.0-originated networks — it’s how WP decides this exact difference in architecture. But in order to detect an MU-originated network, it’s looking for a few other constants: VHOST, SUBDOMAIN_INSTALL, and SUNRISE. If any of those are defined, then multisite will be kicked on in the legacy MU mode, and your install will be looking for hp_1_posts.
Make sense? I’d check out your wp-config.php file and see what’s up.
I try to follow the directions to activate MultiSite
Are you following these directions?
http://codex.wordpress.org/Create_A_Network
Yes I followed the directions at http://codex.wordpress.org/Create_A_Network 3 times and always had the exact same issue.
So not sure what happened, as I said this was a new install of 3.0.5 not an upgrade. WordPress kept complaining that the _1_ blogs did not exist, however once I renamed them it was happy.
If you like I can paste my wp_config here, so you can see what I’m saying better.
No, don’t do that.
If this is a new install, I’d scrub the whole thing and start over. Empty the DB entirely.
Ipstenu, I actually did that 2 times and came with the same answer. That is when I decided to rename the tables, and the issue went away :-).
But like nacin pointed out, it *shouldn’t* be doing that. Hrm.
