• ondrej

    (@ondrej-bilka)


    Hi,
    i’d like to update my MU site to 3.0.1, but I can’t go through some database issue when during installation is wordpress trying to repair tables that are used in one-site installation. In my DB are i.e. wp_1_posts, wp_1_comments etc… any idea?

    wp_posts: Table ‘wordpressB_3.wp_posts’ doesn’t exist
    wp_comments: Table ‘wordpressB_3.wp_comments’ doesn’t exist
    wp_links: Table ‘wordpressB_3.wp_links’ doesn’t exist
    wp_options: Table ‘wordpressB_3.wp_options’ doesn’t exist
    wp_postmeta: Table ‘wordpressB_3.wp_postmeta’ doesn’t exist
    wp_terms: Table ‘wordpressB_3.wp_terms’ doesn’t exist
    wp_term_taxonomy: Table ‘wordpressB_3.wp_term_taxonomy’ doesn’t exist
    wp_term_relationships: Table ‘wordpressB_3.wp_term_relationships’ doesn’t exist
    wp_commentmeta: Table ‘wordpressB_3.wp_commentmeta’ doesn’t exist

Viewing 11 replies - 1 through 11 (of 11 total)
  • Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    Did you do the automatic upgrade or a manual one?

    Thread Starter ondrej

    (@ondrej-bilka)

    Well, it is a little experiment. I did usual manual upgrade, but I couldn’t log in as admin – the login screen was still there.
    So I deleted old config file and had new file created by WP installation. It is possible in older MU versions, but now the >3.0 is both one-site and multi-site and databases are different. Maybe somebody can help me to solve the first issue with that login. ??

    If you’ve got a new config file, you’ve got new login salts & nonces. Clear your browser cache & cookies.

    ondrej, were you able to solve this? I am having the same problem and there next to no information on this problem. Its not a cache or cookie issue, its a poor design issue.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    Its not a cache or cookie issue, its a poor design issue.

    We don’t know that, let’s not jump the gun and point fingers.

    Thus far, I’ve only seen two people (you and ondrej) have the problem, so it’s thus far pretty limited.

    1) How did you upgrade? Did you do the automatic or a manual upgrade?
    2) What version of WPMU were you on? 2.9.2 or 2.9.1 (it does matter a little).
    3) How is your DB structured? Are you using any plugins or special DB configs?
    4) What version of WPMU did you start on?

    Manual upgrade following the guide https://codex.www.ads-software.com/Upgrading_WPMU#2.9.x_to_3.0

    WPMU 2.9.2
    DB structure is the standard WPMU structure:

    +—————————-+
    | wp_XXXX_comments |
    | wp_XXXX_links |
    | wp_XXXX_options |
    | wp_XXXX_postmeta |
    | wp_XXXX_posts |
    | wp_XXXX_term_relationships |
    | wp_XXXX_term_taxonomy |
    | wp_XXXX_terms |
    | wp_blog_versions |
    | wp_blogs |
    | wp_registration_log |
    | wp_signups |
    | wp_site |
    | wp_sitecategories |
    | wp_sitemeta |
    | wp_usermeta |
    | wp_users |
    +—————————-+
    Where the wp_XXXX tables go from 1 to about 4600. db_version is at 11548 for all blogs except 1 that is at version 8204 for what ever reason…

    We have been using wordpress mu sense pre 1.0 beta’s. Upgraded incrementally and database was upgraded as well. No error on last check 20 min ago.

    Update: the orphan database version 8204 was for a blog that no longer exists… wasn’t deleted due to myisam not enforcing foreign key constraints.

    Ok lets amend your installation instructions using a brain this time.

    First after updating to 2.9.2 you have to make sure your sites have the commentmeta table. If you don’t have it use this script: https://ocaoimh.ie/wpmu-add-commentmeta/ and rerun the database update.

    Now You need to add the following to your wp-config.php file to tell the crap installer what your database is:

    define('WP_ALLOW_MULTISITE', true);
    define( 'MULTISITE', true );
    define( 'SUBDOMAIN_INSTALL', false );
    $base = '/';
    define( 'DOMAIN_CURRENT_SITE', 'blogs.site.tld' );
    define( 'PATH_CURRENT_SITE', '/' );
    define( 'SITE_ID_CURRENT_SITE', 1 );
    define( 'BLOG_ID_CURRENT_SITE', 1 );
    
    /* That's all, stop editing! Happy blogging. */

    I also updated my .htaccess file because it differed from the patched version instructed by the codex upgrade guides.

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    # uploaded files
    RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]
    
    # add a trailing slash to /wp-admin
    RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
    
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
    RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
    RewriteRule . index.php [L]

    Now you need to rename your wp_1_ tables because they are going to be the default blog and the schema is different in wp3. Please note that this is not covered ANYWHERE IN ANY F***ING DOCS ANYWHERE!

    RENAME TABLE wp_1_commentmeta TO wp_commentmeta;
    RENAME TABLE wp_1_comments TO wp_comments;
    RENAME TABLE wp_1_links TO wp_links;
    RENAME TABLE wp_1_options TO wp_options;
    RENAME TABLE wp_1_postmeta TO wp_postmeta;
    RENAME TABLE wp_1_posts TO wp_posts;
    RENAME TABLE wp_1_term_relationships TO wp_term_relationships;
    RENAME TABLE wp_1_term_taxonomy TO wp_term_taxonomy;
    RENAME TABLE wp_1_terms TO wp_terms;

    And NOW its finger pointing time and I will let you guess what finger will be doing the pointing.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    That’s very odd… Since I have a 2.9.2 blog that I moved from mu to 3.0 and I did not have to change the table names. In fact they are still the way your before list was… And comment meta SHOULD have been magically added when you upgraded to … I think 2.9.0

    I wonder if you had a bad earlier upgrade that caused that…

    Now You need to add the following to your wp-config.php file to tell the crap installer what your database is:

    uh, no. no, you did not have to do this…

    Now you need to rename your wp_1_ tables because they are going to be the default blog and the schema is different in wp3. Please note that this is not covered ANYWHERE IN ANY F***ING DOCS ANYWHERE!

    It’s not covered becasue you DO NOT HAVE TO DO THIS.

    WordPress *knows* you’re upgrading from wpmu to 3.0. there’s *nothing* you need to do in relation to network stuff.

    Seriously. If there were some lines missing from your confi9g, they were not the ones above, and you missed them in previous upgrades.

    there *are* a handful of threads here with users doing what you’re trying to do (renumbering tables? really? do you really think we’d make you do that?)

    Also! there are numerous threads here details upgrading from wpmu to 3.0. None of them have the steps you did.

    The *only* reason you “had to” renumber tables in your db to “fix” anything was because you put the new network lines in your config. which you do not need to do. Now WP thinks you started out with 3.0. you messed it up.

    @ Andrea_r

    If i DONT HAVE TO DO THIS then why when i follow the upgrade instructions from wordpress mu 2.9.2 after doing all the incremental upgrades does it say that it cant connect to my database when infact all the credential information is correct? Why is the code looking for my wp_* tables that are obviously under the primary blog wp_1_* ? Why does the installer not find this information or repair the database? Why does it work only after I add the additional information to my config for multi-site and rename my tables?

    Who ever developed the migration guide obviously dropped the ball somewhere, be it in the incremental upgrades for wpmu or more than likely during the upgrade check for wp 3.x.

    All of the patched I have outlined in my previous posts were to get the initial installation to FUNCTION. IT WAS BROKEN BEFORE I ADDED ANYTHING TO MY CONFIG OR RENAMED ANY TABLES. Now I don’t really care how it was suppose to work, I am telling you that it currently DOES NOT WORK based on your upgrade documentation. The hacks I applied are all based of what a normal setup should look like after instillation without upgrading and it appears to be functioning correctly for an upgrade.

    “renumbering tables? really? do you really think we’d make you do that?” No, but after looking at your database schema it’s clear that there wasn’t very much thought put into the process. I wish I have more time to spend on this topic but I wasted it all trying to get wordpress updated. Hopefully others upgrading from wpmu will find this post useful.

    P.S. It would be logical to implement some type of cascading database upgrade procedure just in case a revision was missed in the release cycle. A simple switch statement would suffice — Just a thought.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    So to make sure I understand this…

    You upgraded the files.
    You deleted the blogs.php file and updated .htaccess accordingly
    You added in a nonce to wp-config.
    You logged off and logged on.

    At which point you could not access your database.

    I wish you’d posted when THAT happened, instead of running off to your rather non-standard solution. Then perhaps we might have been able to help you before you got in that deep :/

    As Andrea said, you should not have had to do any of that. Somewhere in the middle, something went pear shaped, but there’s no real way to sort that out this late in the game. Sorry you had a shitty upgrade, man, this was generally not the experience I, or others, seem to have had.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Upgrading from 2.9.1 WPMU to 3.0.1 – problem with database tables’ is closed to new replies.