WordPress MU

I'm going to go out on a limb and say it:
The WordPress MU 2.8.4a installer is broken.

This cannot be an isolated problem related to my installation, and I can't be the only person finding this. I started with an empty DB, empty .htaccess file, all perms set correctly, and this problem recurs every time I attempt to install.

When I do a stock install of WPMU 2.8.4a, the installer creates a new user, a new blog, and a new site, in addition to other ancillary information. However, these entries make no sense, and result in the dreaded The blog you have requested is not installed properly. Please contact the system administrator..

The new user record for "admin" has an ID of 2 (not 1).

The new blog created has a blog_id of 2, and points to a site_id of 1. However, the only record in the wp_site table has an ID of 2, so the very first blog created by the installer belongs to a site that does not exist.

Also, the site meta table is populated with data for a single site, with Site ID of 1, which again, does not exist.

Blog ID of 2, Site ID of 1

select * from wp_blogs;
+---------+---------+-------------------+------+--------+
| blog_id | site_id | domain            | path | ...etc |
+---------+---------+-------------------+------+--------+
|       2 |       1 | thedomainname.com | /    | ...etc |
+---------+---------+-------------------+------+--------+

Site ID of 2

select * from wp_site;
+----+-------------------+------+
| id | domain            | path |
+----+-------------------+------+
|  2 | thedomainname.com | /    |
+----+-------------------+------+

select * from wp_usermeta;
+----------+---------+-------------------+---------------------------------+
| umeta_id | user_id | meta_key          | meta_value                      |
+----------+---------+-------------------+---------------------------------+
|        2 |       2 | nickname          | admin                           |
|       12 |       2 | rich_editing      | true                            |
|       22 |       2 | comment_shortcuts | false                           |
|       32 |       2 | admin_color       | fresh                           |
|       52 |       2 | primary_blog      | 2                               |
|       62 |       2 | source_domain     | thedomainname.com               |
|       72 |       2 | wp_2_capabilities | a:1:{s:13:"administrator";b:1;} |
|       82 |       2 | wp_2_user_level   | 10                              |
+----------+---------+-------------------+---------------------------------+

Site Meta table pointing to Site ID of 1, which doesn't exist

+---------+---------+-------------------+--------+
| meta_id | site_id | meta_key          | etc... |
+---------+---------+-------------------+--------+
|       2 |       1 | site_name         | ...    |
|      12 |       1 | admin_email       | ...    |
  etc..., etc...

I think your project is great, guys, but this installer bug is pretty serious. Are there any patches available for this that I may have missed?

I've just installed WPMU 2.8.4a twice within the last twelve hours and am not seeing this problem.

Is there another WordPress install on the server somewhere? Or other CMS software?

Not suggesting your wrong, just trying to narrow things down as I haven't been able to recreate this type of an issue.

There are many WordPress installs on the same server. This has its own virtual host entry and its own completely separate database. The presence of multiple installs is not the problem.

Does the assigned database user have ALL permissions on the database?

Yes.

It should also be noted that the fresh install wp_N_xxx tables have the 1 prefix, which I understand to reference blog ID 1. Again, no blog with ID of 1 exists (or site ID of 1, for that matter).

show tables;
+-------------------------+
| Tables_in_wpmu          |
+-------------------------+
| wp_1_comments           |
| wp_1_links              |
| wp_1_options            |
| wp_1_postmeta           |
| wp_1_posts              |
| wp_1_term_relationships |
| wp_1_term_taxonomy      |
| wp_1_terms              |
| wp_blog_versions        |
| wp_blogs                |
| wp_registration_log     |
| wp_signups              |
| wp_site                 |
| wp_sitecategories       |
| wp_sitemeta             |
| wp_usermeta             |
| wp_users                |
+-------------------------+

Given what you reported in the first post, something is tripping the count.

I can't reproduce it either.

What OS are you on?
Do the wp_1_X tables have the right info in it?
Can you change all the 2s to 1s and see if that magically works?

CentOS, standard Apache2/PHP 5.2.6/MySQL 5.0.41 install.

Obviously, as this is a fresh install, most of the wp_1_xxx tables are empty. wp_1_options does contain reasonable values.

I've tried changing the IDs of 2s to 1s before, which did magically fix the site, but that doesn't really solve the problem. If I remember correctly, it caused some other issues, as well.

"most of the wp_1_xxx tables are empty. "

They should have default values in them.

"If I remember correctly, it caused some other issues, as well. "

Can you try and find out what they were?

No, fudging it doesn't fix the original problem, but at this point where we can't reproduce the issue (even on the same server setup) I can't really say it's a bug. But it will get you running.

Who's your webhost? (some have had issues with MU)

Finally, after triple checking the DB settings, we figured out the problem. We're hosting this site on an internal cluster of machines, and the dev DB server we're testing this on used to be part of a Master-Master setup, so its autoincrement values were set to increment in 10s, starting with 2.

Since the blog and site creation SQL sends a NULL value to the ID field (a reasonable thing to do on an insert), the autoincrement value gets set to whatever the server thinks it should be. However, the source of this particular problem is because the inserts assume this value will be 1 on a fresh install.

While this is a strange case, it's certainly not out of the realm of other setups, and could easily be addressed by doing a select on the id of the first site and blog created, instead of assuming values of 1.

Off to hack the installer to read these values so I can get through a sane install...

Hopefully this keeps someone else from scratching their heads!

Aha!

So, it is a bug in rare cases.

Feel free to file a trac ticket here:
http://trac.mu.wordpress.org/

Login with the same user/pass you have here in the forums. If you have a diff with the code change, even better.

Well I'm glad you've found it, it is pretty obscure though and as Andrea says filing it as a bug in trac is worth doing because it could bite someone else on the ass sometime.

Ticket filed, with patch for fix.

http://trac.mu.wordpress.org/ticket/1123

it's possible to have the patch included in the release?
having values of auto_increment_increment and auto_increment_offset different from default is quite common, especially if mysql replication is needed.