kwhat4

@ 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.

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.

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.

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.