WordPress MU

I'm having trouble completing a clean install of WordPress MU 1.0 (from latest.tar.gz, downloaded today). After filling out the first configuration form I get a page full of WordPress database error messages, all telling me that 'Table [db_name].wp_1_options' doesn't exist.

This is NOT the problem so widely reported here wherein the table gets created despite the error message. When I go check the database I can see that no tables have been created. Oddly enough I _do_ get emailed my account credentials, but I am unable to use them. When I try to load various pages I get "No WPMU site defined on this host."

When I run mysql from a shell using the same credentials I supplied to WordPress MU I am able to get, create and drop tables, etc.; I don't know why the application itself is unable to do so.

My setup: Apache 2.0.5.3, PHP 4.3.9, MySQL 4.1.10a running on RedHat Enterprise Linux.

I've tried removing wp-config.php and repeating the process, as well as deleting everything, re-downloading latest.tar.gz, and starting fresh, but I keep having the same problem. Can anyone offer any advice?

Thanks,

Songdog

I tried giving WordPress MU the MySQL root account credentials but I got the same set of errors. Again, accessing mysql from the shell I have all privileges within my test database.

More tests, none of which have helped:
-> There were underscores in my database and user name. I've tried with a different database and user.
-> I've tried referencing the database server (which is on localhost) via other names: its network name, its fully qualified domain name, etc.
-> I've was only granting the WPMU MySQL user access from localhost. I've tried expanding this to allow access from _anywhere_ on the Net.

For what it's worth I also tried changing the database name to a garbage value in the WPMU installation form. When I submit then WPMU tells me that it is at least able to use the username and password to reach the designated MySQL _server_.

I don't understand why, if WPMU knows it can reach the server, and is happily reporting the non-existence of essential tables, it is apparently unaware that it has failed to _create_ those very same tables.

I also don't understand why, after reporting a long page of errors trying to access those missing tables, WPMU is giving me the "Congrats! Your WPMU site has been set up" message and sending me a welcome email.

Is there additional information that I can provide to the community that might help someone recognize the nature of this problem?

Thanks,

Songdog

Just throwing a bone out here, but I was going to wonder about 4.3.9 for PHP, until I remembered that one of my local test boxes (my bare minimum box) has 4.3.4 loaded on it, and it works fine.

MySQL 4.1 should be OK, I have it on my production boxes, and MU didn't have any trouble.

Let me ask a really off the wall question though.

Is there any funky special characters in your db password that could potentially be causing a problem?

Maybe an apostrophe, double quote mark, pipe character, or something?

usernames and db names with underscores are fine, I use them all the time just so phpMyAdmin's little dropdown box organizes my sites in a format I can glance at quickly and find what I want.

Apache shouldn't be the problem either with this particular error.

Maybe it's a php/mysql version compatibility problem or something? On my 4.3.4 box, it's only running mysql 3.23.xx since as i mentioned it's a bare minimum box.

Is there nothing in the error logs that might lend a clue?

If need be, you could (temporarily) turn on the option for errors to be printed on the screen in php.ini, just don't forget to turn it back off once you watch the script run.

This may sound bad, but you are following the install instructions precisely, right? Not perhaps overlooking something?

Does the db user have full access to the db in question? read, write, create, drop, alter, etc?

Thanks for replying, lunabyte. I turned on display_errors for the moment and I discovered this series of errors, which appears before WPMU tries to access the tables it failed to create:

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 4

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 18

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 20

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 22

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 24

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 26

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 28

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-includes/vars.php on line 28

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 689

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 693

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 696

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 699

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 689

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 693

Warning: preg_match: internal pcre_fullinfo() error -3 in /world/blogtest/wp-admin/upgrade-functions.php on line 696

And so on. To reiterate, I'm on Apache 2.0.5.3, PHP 4.3.9, MySQL 4.1.10a and RedHat Enterprise Linux.

-Songdog

Also, phpinfo() shows --with-pcre-regex=/usr', with PCRE enabled and PCRE library version 3.9 02-Jan-2002.

Three PHP bug reports (all flagged as "bogus") reference this issue: #29158, #29914, and #31501. It sounds like it may be a problem that our PHP build is set to use the "wrong" PCRE regex library.

Does anyone here know more about this?