WordPress MU

When I create a new blog via the admin panel, I get this error:

WordPress database error: [Table 'wordpressmu.wp_8_options' doesn't exist]
SELECT option_value FROM wp_8_options WHERE option_name = 'wp_8_user_roles' LIMIT 1

WordPress database error: [Table 'wordpressmu.wp_8_options' doesn't exist]
SELECT option_value FROM wp_8_options WHERE option_name = 'blogname' LIMIT 1

WordPress database error: [Table 'wordpressmu.wp_8_options' doesn't exist]
SELECT option_value FROM wp_8_options WHERE option_name = 'siteurl' LIMIT 1

WordPress database error: [Table 'wordpressmu.wp_8_options' doesn't exist]
SELECT option_value FROM wp_8_options WHERE option_name = 'post_count' LIMIT 1

Warning: Cannot modify header information - headers already sent by (output started at /data/wordpressmu/wp-includes/wp-db.php:135) in /data/wordpressmu/wp-includes/pluggable.php on line 334

I have looked through various support tickets, etc., and made the changes to the files, but still this occurs.

Also, when deleting a blog, I get the following error:

WordPress database error: [Table 'wordpressmu.wp_7_options' doesn't exist]
SELECT option_value FROM wp_7_options WHERE option_name = 'wp_7_user_roles' LIMIT 1

Warning: Cannot modify header information - headers already sent by (output started at /data/wordpressmu/wp-includes/wp-db.php:135) in /data/wordpressmu/wp-includes/pluggable.php on line 334

There are a couple topics on the front page with this.

I am getting the same errors. I recently reuploaded wp-mu to 1.1.1, and did not get those errors when I was an older version of WPMU. At the time, my MySQL was 4.1. Now, for test purposes, I chose to use the MySQL 5.0 to see how it would work, and now I'm getting errors.

Everything goes through ok, the blog is created, and it works. It's just the db-errors I get.

Actually I got it this morning as well.

Donncha's aware of it though:

http://mu.wordpress.org/forums/topic.php?id=3491

Check the memory limit allowed for PHP in php.ini, and bump it up so it's 16M or more. See if that helps.

See this thread for an ongoing dialog.

Should I update the README and the download page with a message about increasing memory size? It will bite more and more people as plugins are added and things get bigger with time..

It might help Donncha.

That seems to be the logical fix at the moment.

The only downside is shared hosts that won't up the limit, but it might be possible for them to add a dir into htaccess.

That'd be good - btw do you reckon I'll ever need more than 128?

"Ever"? Oh yeah, sure. Someday.

A village idiot, who also goes by William Gates, one said, "500MB? Who will ever need more than that!"

Actually they're now saying he never said that.

I gotta disagree that memory would be causing a Can't find table error though...

If it runs out, and doesn't make it, maybe.

Strange, strange things happens when PHP runs low or out of memory.

I gotta disagree that memory would be causing a Can't find table error though...

In my case I had only about 30 recently created blogs and no plugins. The only addition I had made that uses any memory is a 130k translation file.

I've got two problems at the moment - both of them pretty big regarding new blog creation...

New blog creation via wp-signup.php is working great on eslblogs (700 odd blogs) but not on uniblogs (5K) and learnerblogs (20K+).

On Uniblogs once a new blog is created everything goes fine until we get to the activate link - which then brings up this: bunch of errors (and adsense???):
http://incsub.org/blog/wp-content/uploads/2007/03/newblogerror.gif

While creating a new blog on learnerblogs through wp-signup.php gets a little further (no adsense or errors) and creates a user and semi-creates a blog - backend produces this error:

WordPress database error: [Table 'learnerb_wpmu2.wp_21645_options' doesn't exist]
SELECT * FROM wp_21645_options WHERE option_name NOT LIKE 'rss%' AND option_name NOT LIKE '%user_roles')

And the message 'blog already exists' pops up on activation... so it's still useless :(

As for creating blogs through the backend - that just isn't working for me - but more on that later.

The config is exactly the same on each site and they're sitting on the same server - so it *must* be something to do with the size of the site (they're all still single databases) and the the new blog creation script... right?

Cheers, James

Any max execution errors in the log?

Will have a look - I reckon this is the same problem that I had with edublogs a bit back - it seems that 1.1.1. is even less big site friendly than 1.0 when it comes to creating new blogs :(

I've noticed some "irregularities" as well.

I'm still sorting through it though.

After running full tests on the same thing locally, "something" is funny with my live site.

Like the permalinks issue I made note of in another thread, and I've noticed a few things in the back end that I'm making notes of as well.

Ones I can verify, I'll add to whichever trac it would apply to.

Oh, also...

What's exactly different between the two setups? I notice you didn't mention having that issue with the edu site.

The problem is that make_db_current_silent() is taking so long that a time out occurs when creating a new site.

There are a few *temporary* ways around this issue but if anyone can figure out what's actually causing the time out i'll be thrilled.

Hmmmm. Interesting.

I wonder why it's eating so much. If I get a chance soon I'll look into it.

I wonder if maybe a better "option" would be for that script to run the next time the site is loaded. Set an option flag, then it runs it individually per site as that site is used.

Of course, the script will have to slim down some, if indeed it's eating a lot.

I had a similar problem. Admin panel gave me a "not enough memory" sort of message when creating a new blog, even though the new blog actually WAS created (checking the tables showed that it was).

I upped "memory_limit" in php.ini to 16M (it was at 8) and everything is now working fine.

You may wish to consider a slightly higher setting.

I'd recommend 128M, but no less than 64M.

Reason being, once the system gets really, really active, PHP will need it. Especially when performing things like updates such.

Provided you have the RAM available, of course.

I conur with a "Oh heck yeah!" :D MU likes to snack on RAM constantly.

a) This should definitely end up in the readme to avoid repeating of the same mistakes.
b) The errors should be caught by some(?) handler, it should not just die half way...

http://trac.mu.wordpress.org/browser/trunk/README.txt#L52

It is in the Readme file. Has been for a quite some time now.

My bad, thanks.

Another reason why it's not a good idea to run mu on a shared host. I don't think many admins will approve a fix up to 128megs for php.