The MU forums have moved to WordPress.org

Creating Blog Errors -- New Information (11 posts)

  1. stormerider
    Member
    Posted 17 years ago #

    I've searched the forums and read the posts. However, I'm not sure that the current thought that memory errors are causing table creation to fail is correct. I'm running WP-MU under phpSuExec with PHP 5.1.4 and I'm not seeing any errors about running out of memory in the server error_log nor the error_log file in the web account root.

    I've upped the memory_limit to 32 in php.ini and restarted apache, however when I check phpinfo, I don't even see an entry at all for memory_limit. I then wrote a script like:

    $inis = ini_get_all(); print_r($inis);
    and it was not listed there, either.

    This only happened after I went from 1.0 to 1.1.1. I'm trying to compare the versions to see if I can locate anything obvious, but there's a lot that changed, so it's a bit difficult.

    I added some debugging code and I am seeing make_db_current_silent called, but after the first 4 SELECT queries. Adding further code, I looked at $wp_queries and saw it was trying to create wp_1_categories... and this is after switch_blog_id has already been called. $wp_queries does not get updated after switch_blog_id is called, so the table WP is trying to create is not for the new blog and has no effect.

  2. stormerider
    Member
    Posted 17 years ago #

    /bump

    This does not appear related to memory usage at all... this appears to be a code-related bug. Has anyone had a chance to look further into this?

    Thanks.

  3. drmike
    Member
    Posted 17 years ago #

    I'm not sure that the current thought that memory errors are causing table creation to fail is correct.

    I don't either actually. I really haven't had time to look into it myself.

  4. zappoman
    Member
    Posted 17 years ago #

    Which errors are you referring to? I saw some errors related to certain columns not having default values related to creation of new blogs. But I am sure this is related to a compatibility nuance in MySQL 5.x. I worked around this problem by patching the INSERT calls to include those columns that can't have NULL.

    But from this thread it's not clear to me if this is the same error you are seeing.

  5. stormerider
    Member
    Posted 17 years ago #

    When I go to create a blog, this is what I get, running 1.1.1 on mysql 4.1 (not 5.x):

    WordPress database error: [Table 'authors_wpmu.wp_23_options' doesn't exist]
    INSERT INTO wp_23_options (option_name, option_value, option_description, autoload) VALUES ('siteurl', 'http://authorsabode.com/wp-signup.php/wp-signup.php', 'WordPress web address', 'yes')

    WordPress database error: [Table 'authors_wpmu.wp_23_options' doesn't exist]
    INSERT INTO wp_23_options (option_name, option_value, option_description, autoload) VALUES ('blogname', 'My Weblog', 'Blog title', 'yes')

    The rest continues, but I snipped it as it becomes irrelevant.

    As I mentioned before, as far as I can tell, this is because the SQL to create the tables does not change when switch_blog_id(23); is called. $wpdb->options still points to wp_1_options rather than wp_23_options, so wp_23_options is never created.

    It would seem to me that the SQL should not be stored as a static string ($wp_queries), but generated in a function when needed. This way, it will be generated after switch_blog_id has been called and $wpdb->options has been updated.

    Does this logically follow for other folks?

    This may be an issue with some folks using the Zend Optimizer, and others not, which may be why it works for some people and not others. My cPanel installation does use the Optimizer.

  6. drmike
    Member
    Posted 17 years ago #

    Snipped a lot more out of there. Bloodly hell...

    All Cpanel installs use Zend Optimizer. It's a required part of the install.

  7. zappoman
    Member
    Posted 17 years ago #

    Stormerider, sorry, but my experiences were with MySQL 5.x... so I can't help you on this. Good luck!

  8. stormerider
    Member
    Posted 17 years ago #

    Ok... I went with my gut instinct and I moved it to a function rather than having it as a static string, and the problem was solved. Here's a diff from SVN:

    Index: wp-admin/upgrade-functions.php
    ===================================================================
    --- wp-admin/upgrade-functions.php      (revision 906)
    +++ wp-admin/upgrade-functions.php      (working copy)
    @@ -897,18 +897,18 @@
     }
    
     function make_db_current() {
    -       global $wp_queries;
    +       //global $wp_queries;
    
    -       $alterations = dbDelta($wp_queries);
    +       $alterations = dbDelta(get_wp_queries());
            echo "<ol>n";
            foreach($alterations as $alteration) echo "<li>$alteration</li>n";
            echo "</ol>n";
     }
    
     function make_db_current_silent() {
    -       global $wp_queries;
    +       //global $wp_queries;
    
    -       $alterations = dbDelta($wp_queries);
    +       $alterations = dbDelta(get_wp_queries());
     }
    
     function make_site_theme_from_oldschool($theme_name, $template) {
    Index: wp-admin/upgrade-schema.php
    ===================================================================
    --- wp-admin/upgrade-schema.php (revision 906)
    +++ wp-admin/upgrade-schema.php (working copy)
    @@ -1,7 +1,7 @@
     <?php
     // Here we keep the DB structure and option values
    
    -global $wp_queries;
    +//global $wp_queries;
     $charset_collate = '';
    
     if ( version_compare(mysql_get_server_info(), '4.1.0', '>=') ) {
    @@ -11,6 +11,9 @@
                    $charset_collate .= " COLLATE $wpdb->collate";
     }
    
    +function get_wp_queries() {
    +       global $wpdb, $charset_collate;
    +
     $wp_queries="CREATE TABLE $wpdb->categories (
       cat_ID bigint(20) NOT NULL auto_increment,
       cat_name varchar(55) NOT NULL default '',
    @@ -228,6 +231,8 @@
       KEY domain (domain)
     );
     ";
    +       return $wp_queries;
    +}
    
     function populate_options() {
            global $wpdb, $wp_db_version, $wpblog, $current_site;

    I'm not sure if this breaks any compatibility with WP2.2, but I think it's probably the right way to handle it... or at least a step in the right direction.

  9. drmike
    Member
    Posted 17 years ago #

    Best bet would be to submit it to trac and have Donncha take a look at it.

    http://trac.mu.wordpress.org

  10. stormerider
    Member
    Posted 17 years ago #

    Should I make a new ticket on this? I don't see an active ticket. I think part of the problem people are having is that if they do search through the forums they see the post from several months ago pointing to Trac ticket #184 which is closed.

    No offense, but it makes more sense to me if you can point people to an active ticket than tell them to search through the forums only to find a reference to a ticket marked as fixed when the issue has cropped up again.

  11. treepour
    Member
    Posted 17 years ago #

    Not sure if this exactly the same problem or not, but thought I'd offer this . . .

    I found that php stopped executing in wp-admin/upgrade_schema.php where the $wp_queries string is created. I tried altering the size of the string and discovered that php was choking when the string started getting large (I don't recall the cutoff, but it was somewhere near 1/3 to 1/2). This made me think that that a memory limit problem was actually a likely possibility. Indeed, upping the php memory limit from 8M to 16M solved the problem.

About this Topic

  • Started 17 years ago by stormerider
  • Latest reply from treepour