Blogs will not install upon creation.

When users try to create a blog, a number of those created (and now, almost all of them) are not created, and instead, we receive the following error: "The blog you have requested is not installed properly. Please contact the system administrator."

We have looked through a multitude of tickets and forum topics on the subject, but we have not located an answer to this problem. Earlier today, I defaulted the config's Default Charset option from utf8 to an empty string, per the random advice from forum topics, and it seems like we've not had any luck so far. This issue has been going on for months. We've been able to avoid the issue slowly as the site grew by disabling some of the bulkier plugins from the WPMU site (Firestats and Sociable among them). But now, with over 1,000 registered blogs, the problem has become nigh unavoidable.

Has anyone been able to discover the root of this problem, and if so, how have they fixed it? I know a bunch of WPMU admins simply delete broken blogs and create new ones for the users, and this was our solution for those sporadic cases in April and earlier this month, but now it seems almost every blog fails upon creation. To top it off, we can't use the admin Add Blog feature anymore - the page halts during execution, throws back an error, and the blog is half-created just like the blogs that users attempt to create (to specify, records exist, but the blogs do not load, and users are not linked to those blogs). The other popular solution is to completely reinstall the platform, which we will do in time, but I don't want to find that the problem recurs after 500 blogs on a newer installation.

Our website is

We use WordPress MU 2.6. We do not use multi-DB or any scaling solution, and we do not use BuddyPress. We do, however, have plans to recreate the WordPress install using WPMU for WP 2.8 with the 256 table Multi-DB solution and BuddyPress (should Multi-DB and BuddyPress be able to coexist).

Here is our config file, sensitive information x'd out:
/* Don't try to create this file by hand. Read the README.txt and run the installer. */
// ** MySQL settings ** //
define('DB_NAME', 'xxxxxx'); // The name of the database
define('DB_USER', 'xxxxxx'); // Your MySQL username
define('DB_PASSWORD', 'xxxxxx'); // ...and password
define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value
define('DB_CHARSET', '');
define('DB_COLLATE', '');
define('VHOST', 'yes');
$base = '/';

// Change each KEY to a different unique phrase. You won't have to remember the phrases later,
// so make them long and complicated. You can visit
// to get keys generated for you, or just make something up. Each key should have a different phrase.
define('AUTH_KEY', 'xxxxxx'); // Change this to a unique phrase.
define('SECURE_AUTH_KEY', 'xxxxxx'); // Change this to a unique phrase.
define('SECURE_AUTH_SALT', 'xxxxxx'); // Change this to a unique phrase.
define('LOGGED_IN_KEY', 'xxxxxx'); // Change this to a unique phrase.
define('SECRET_KEY', 'xxxxxx'); // Change these to unique phrases.
define('SECRET_SALT', 'xxxxxx');
define('LOGGED_IN_SALT', 'xxxxxx');

// double check $base
if( $base == 'BASE' )
die( 'Problem in wp-config.php - $base is set to BASE when it should be the path like "/" or "/blogs/"! Please fix it!' );
// You can have multiple installations in one database if you give each a unique prefix
$table_prefix = 'wp_'; // Only numbers, letters, and underscores please!

// Change this to localize WordPress. A corresponding MO file for the
// chosen language must be installed to wp-content/languages.
// For example, install to wp-content/languages and set WPLANG to 'de'
// to enable German language support.
define ('WPLANG', '');

// uncomment this to enable wp-content/sunrise.php support
define( 'SUNRISE', 'on' );

// Uncomment and set this to a URL to redirect if a blog does not exist or is a 404 on the main blog. (Useful if signup is disabled)
// For example, browser will redirect to for the following: define( 'NOBLOGREDIRECT', '' );
// define( 'NOBLOGREDIRECT', '' );

define( "WP_USE_MULTIPLE_DB", false );

/* That's all, stop editing! Happy blogging. */

if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

require_once(ABSPATH . 'wp-settings.php');

  • Barry
    • DEV MAN’s Mascot

    Ok, I've got an idea of what it could be, but let's do some testing first.

    Can you phpmyadmin (or however you access it) into your database and try to create a new table. Try one of the queries (with an edit to the table name) in schema.php (can't rememember the directory off the top of my head).

    Did it create the table? Did you see any errors or messages?

    If that worked, try it again with the username and password of the account WPMU is using (OR change the username and password of WPMU to the root one phpmyadmin is using).

    My thinking so far is a database size limit has been reached, so the first query you run (if this is the case) should error with an informative message.

    • WPMU DEV Initiate

    Cafespain: That was my hunch, too. For about a month now, I've been unable to access PHPMyAdmin, so I couldn't run the test that way. Moreover, I haven't been able to access the database using the command line either, since the 'use' command starts up but never finishes.

    Okay, so I made a testing file and ran the schema.php queries, but I ran into no errors. This was with the same username and table as the WordPress MU setup.

  • Barry
    • DEV MAN’s Mascot

    Did it create the tables ok?

    Are you on your own host (own installed software, etc.)? I think at this point it might be worth popping a message to your hosts support if they are available, at least to get you back into phpmyadmin or the command line access so you can see what's going on.

    • WPMU DEV Initiate

    Cafespain: The tables were created. Our host is Rackspace, and we're able to access PHPMyAdmin and the command line. It's just that, for some reason, using the WPMU database through the command line or PHPMyAdmin times out when loading the tables. I will, though, still send a ticket about the time out issue.

    Do you think the issue could lie in the massive size of the database? We use plenty of plugins, so it wouldn't surprise me that the number of tables could range in the tens of thousands.

  • Andrew
    • Champion of Loops


    PHPMyAdmin will often time out with that many tables.

    Since the tables are being created you probably have a plugin causing the problem. First remove all plugins to confirm that it is indeed a plugin issue. If it is then add the plugins back in one at a time until you find the one that causes the problem.


  • drmike
    • DEV MAN’s Mascot

    There's a config setting to limit how many tables and records are displayed. You can;t make changes if you;re on a shared account but if it;'s your own server or VPS, should work fine. (We do this as a default on ours.)

    And of course I can't find it anywhere in phpMyAdmin's docs....

    Here it is:

    $cfg['MaxDbList'] integer
    The maximum number of database names to be displayed in the navigation frame and the database list.
    $cfg['MaxTableList'] integer
    The maximum number of table names to be displayed in the main panel's list (except on the Export page). This limit is also enforced in the navigation panel when in Light mode.

    I believe we finally decided on 100 for each.

    • WPMU DEV Initiate

    Andrew, the plugin issue occurred to us, and that's how we started to solve the issue. At first, we thought the problem was in some of our plugins, and often deactivating a plugin would resolve the issue for a short amount of time. We went through every plugin one by one to ensure that nothing was causing any deliberate problems, and we did not find any show-stopping issues. That said, the problem has resumed even with the previous larger plugins all deactivated, which leads me to think that if I want to get the blogs to register again, I need to turn off more plugins.

    Sooner or later, all the plugins could be deactivated, and we could genuinely be unable to prevent this issue any further.

    • WPMU DEV Initiate

    Oh, absolutely. We have installed a number of premium plugins, and I'm pretty certain that none of them in particular cause the problem. We're just highly frustrated over here, trying to figure out how we can fix the issue now or avoid this issue later.

    Just to throw some ideas out - do you think using Multi-DB will ease up the problem by lightening database load? And in that case, would it be smarter to partition these databases over multiple servers, or would we be okay on the same one?

    • WPMU DEV Initiate

    Andrew, any thoughts as to where else the problem could lie? It doesn't seem to have to do with plugins, since I can deactivate or activate plugins and the new blog creation process only seems to get worse with more blogs created.

    Edit: I've deactivated a number of non-critical plugins. Here's hoping for some success again. I think we've had 60 registrations in the past week, and almost all of them completely failed.

    • WPMU DEV Initiate

    Nope. Aside from one error at trying to access a blog ("The blog you have requested is not installed properly.":wink:, we're not getting any errors.

    However, it seems to happen right at the time that the user activates their account. Typically, the page will stop loading after the header and before the footer.

    • WPMU DEV Initiate

    We are not.

    Blogs have started registering again after deactivating plugins that were previously unrelated to the problem. These plugins were "What Would Seth Godin Do" and "WP-PostRatings". I imagine I'll be revisiting this issue again sooner or later.

    Thank you for your assistance so far.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.