WordPress.org

Ready to get started?Download WordPress

Forums

DB tables for new subdomain site fail to get created (60 posts)

  1. zaneselvans
    Member
    Posted 3 years ago #

    I've got WP 3.0.5 running in a subdomain install, with the domain mapping plugin. It's been working fine. I created up 5 blogs initially, and then installed the subdomain mapping plugin, and got it working fine. Several weeks passed, with writing and plugin isntallation/removal and all the other little changes that take place over time, and now I'm trying to create another new site, and it's failing.

    When I look at the DB tables, the information for the new site is showing up in the Network wide tables (wp_blogs, etc) but it's failing to create the new wp_N_posts, wp_N_comments, (etc) tables that would hold the content for that particular blog. The DB user has all privileges on the table of the blog DB, and I don't see any explicit errors showing up in the debug.log pertaining to the table creation -- though a huge number of them appear when it tries to actually *do* anything with those (non-existent) tables.

    Any ideas?

  2. though a huge number of [errors] appear when it tries to actually *do* anything with those (non-existent) tables.

    Well that one is obvious, right? :) No tables = errors when you call them ;)

    Okay. So first step would be to see if YOU can make more tables manually. Go in via phpMyAdmin and just make a test table. Since you've been able to make tables before via WP, we know your ID has access, so it shouldn't be THAT. But if WP's getting a weird error, it may not kick out cleanly.

    (There's an idea - After creating a subsite WP checks to make sure wp_#_options exists and, if not, says there's an error and goes no further... or cleans up what it did.)

  3. Someone else ahs a thread complaining they can't make new blogs after installing domain mapping. turn it off for 5 minutes, create a new blog. Does it work then?

  4. zaneselvans
    Member
    Posted 3 years ago #

    I did already try opening up mysql and creating a test table in the WP DB, and it worked fine. So I don't think it's a permissions thing.

    What's the right way to turn off domain mapping? Can I just comment out the SUNRISE line in my wp-config file, or do I need to remove the mu-plugins directory, etc? I tried just commenting out SUNRISE and it didn't fix the blog creation problem. Hmm.

  5. comment sunrise and remove the plugin from mu-plugins (or rename it .txt)

  6. zaneselvans
    Member
    Posted 3 years ago #

    Okay, I get the same behavior with domain mapping turned off: apparent success in creating the blog, existing tables (e.g. wp_blogs) are altered, but no new tables are actually created. Grr.

  7. Is your DB out of space?

  8. zaneselvans
    Member
    Posted 3 years ago #

    I doubt it, since I have my own VPS and I'm not having any trouble adding entries to other tables, and there's no shortage of disk space. Is it possible that there could be a (very low) default quota set within mysql itself? I've never used quotas in mysql... not sure how to check that. Permissions on the directory that the DB files are stored in look okay too (all owned by mysql:mysql 660, directory is 700).

  9. zaneselvans
    Member
    Posted 3 years ago #

    Ugh. For no apparent reason, the problem has now gone away. All that happened in the meantime was that I re-activated domain mapping, and mapped a domain to one of the existing blogs. And now suddenly I can create a new blog, and all the DB tables get created just fine. So it seems that the problem is with the domain mapping plugin somewhere.

  10. Have you looked at any error logs? That's not a lot for the devs to go on....

  11. zaneselvans
    Member
    Posted 3 years ago #

    I wasn't able to find any useful error logs. Just a spew of errors when WP tried to do things with the tables that should have been created but weren't. Where would you suggest looking?

  12. new updates to the plugin coming soon for 3.1 too.

  13. zaneselvans
    Member
    Posted 3 years ago #

    Just updated to 3.1, and so far I like it -- the separation of network from individual site administration is much cleaner

  14. zaneselvans
    Member
    Posted 3 years ago #

    So, I'm now running 3.1.1 and trying to create another blog in my network install, and am having exactly the same problem. The new tables just don't get created. The DB user that the site is running under has all privledges on the DB, and I still don't know where to find any potential DB error logs. Tried disabling domain mapping (which in some mysterious way temporarily fixed this issue before) but it didn't seem to work. AUGH!

  15. I'm fishing...

    What versions of PHP and MySQL are you using?

    Is your DB using MyISAM?

  16. zaneselvans
    Member
    Posted 3 years ago #

    mysql --version yields:

    mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (x86_64) using readline 6.1

    output from phpinfo() can be seen here:
    http://zaneselvans.org/php-version.php

    and indicates I've got PHP Version 5.3.2-1ubuntu4.7

    In my DB datastore, I see .MYD and .MYI files, so I assume I'm using MyISAM. It's the default, right? I didn't tell it to do anything special on install.

    insert_blog() appears to be succeeding, as the wp_blogs table is updated with the new blog_id, domain, etc. But then install_blog() is failing -- none of the additional tables are actually created. I tried changing the call to wp_db_current_silent() to wp_db_current() in hopes of getting some kind of error/progress output within install_blog() inside ms-functions.php but got nothing.

  17. zaneselvans
    Member
    Posted 3 years ago #

    It's like it isn't even *trying* to create the tables, rather than trying and failing. I don't see anything related to the table creation debug.log. Is there some way to get it to print out the $wp_queries that is being used? I uncommented several echo lines in the dbDelta function inside upgrade.php, apparently meant to output the database queries being processed, but didn't get the output anywhere I could see.

  18. Try making a NEW database user in SQL and give it full permissions. Then update your wp-config.php to use that?

  19. zaneselvans
    Member
    Posted 3 years ago #

    Poking around some more, at the beginning dbDelta if I output the contents of $queries to the error log, I get a nice big pile of table creation SQL statements. Near the end of dbDelta though, if I output the contents of $allqueries inside the loop where the actual query execution is being done by $wpdb, it's empty. In fact, nothing inside that foreach loop gets executed, because there's nothing in $allqueries to iterate over. So somewhere in between the queries are getting munged to nothing.

  20. zaneselvans
    Member
    Posted 3 years ago #

    My guess is it's detecting a table name collision because it's confused about what blog it is, and the CREATE statements are getting filtered out because that table "already exists". Here's one of the CREATE TABLE statements from the error log:

    [15-Apr-2011 00:29:11] CREATE TABLE wp_terms (
    term_id bigint(20) unsigned NOT NULL auto_increment,
    name varchar(200) NOT NULL default '',
    slug varchar(200) NOT NULL default '',
    term_group bigint(10) NOT NULL default 0,
    PRIMARY KEY  (term_id),
    UNIQUE KEY slug (slug),
    KEY name (name)
    ) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci

    Shouldn't it be CREATE TABLE wp_48_terms, since 48 is the current blog_id? Or is that number automatically inserted by the $wpdb object when it executes the query?

  21. zaneselvans
    Member
    Posted 3 years ago #

    The line that's nuking $cqueries (the CREATE TABLE statements) is

    unset($cqueries[strtolower($table)]);

    $table is being set by an earlier call to:

    $wpdb->get_col('SHOW TABLES;')

    so it is some kind of name collision, with the appropriate blog_id not being present in the CREATE TABLE statements, it thinks you're trying to create tables that already exist, and so skips that step. Now, *why* is that the case? Where are the table names being set, and why aren't they getting the blog_ids?

  22. still giving
    Member
    Posted 3 years ago #

    I am coming against this same error/bug/whatever too.

    New sub-domain blogs appear in Network Admin but not in the database or blogs.dir.

    What I find strange is the link to 'Visit' the failed blog in Network Admin > Sites > Sites is http://example.com/wp-admin/network/sites.php not http://blog2.example.com/ as should be.

    Scouring the web, it seems this comes up often. WP-MS really should kick out some kind of error when it comes across this.

    Thanks

  23. zaneselvans
    Member
    Posted 3 years ago #

    Hmm. So when I try and access $wpdb->$blog_id it appears to be unset. It's like the DB doesn't think it's running in a multi-site/network environment. If I access global $blog_id it's correct. Even if I do switch_to_blog($blog_id), using the global $blog_id, $wpdb->$blog_id is still unset. Maybe the $wpdb object is getting instantiated in the wrong context somehow?

  24. zaneselvans
    Member
    Posted 3 years ago #

    That bad link (to network/sites.php) is just what happens when no URL is inserted into that link -- A link to a blank URL is the same as a link to the same page you're on.

    I tried de-activating all of my network activated plugins, and I still couldn't create a new blog.

    Creating a new DB user with all privileges and using it instead in wp-config.php also had no effect.

    I'm going bananas here. Anybody have any suggestions?

  25. still giving
    Member
    Posted 3 years ago #

    I can only say, I am feeling the same pain ...

    To add, when I look at Update Network

    I get the error:

    Warning! Problem updating . Your server may not be able to connect to sites running on it. Error message: A valid URL was not provided.

    I don't know if this is a clue ... somewhere in the box, an incorrect URL has been added?

    Where does WP-MS actually keep a record of the ID number? I delete test blogs but the ID number keeps rising.

    Thanks

  26. zaneselvans
    Member
    Posted 3 years ago #

    The blog_id is stored in the wp_blogs table. It's an auto-increment value. The DB keeps track of the ID and increments each time a new set of blog tables is created; deleting them doesn't decrement the counter.

  27. zaneselvans
    Member
    Posted 3 years ago #

    If I really want to debug this, and find out what combination of stuff is screwing it up, what's the right way to set up a testing/debugging environment? Creating and destroying broken blogs on my live network install is not optimal...

  28. zaneselvans
    Member
    Posted 3 years ago #

    I think this problem might be related to this bug: https://core.trac.wordpress.org/ticket/12028

    Looking at the $wpdb object, just before dbDelta is called, everything looks fine, but $wp_queries doesn't have the right table prefixes in the CREATE statements. It seems like there needs to be a way to force an update of $wp_queries using the current blog or a particular $wpdb object.

    Or maybe there is a way to do this already?

  29. zaneselvans
    Member
    Posted 3 years ago #

    Well, I created a little wrapper function generate_wp_queries and put a copy of the queries from schema.php in it, and used it to create my new tables, and it seems to be working fine. But it's ugly. I put the code back to the way it was afterward to avoid any future consequences of the change.

  30. what's the right way to set up a testing/debugging environment? Creating and destroying broken blogs on my live network install is not optimal...

    Then set up a local install, or one on a spare domain in a spare account, or one in a subfolder account as a subfolder setup... lots of choices.

Topic Closed

This topic has been closed to new replies.

About this Topic