Migrate 3.6 to actual 3.6

What’s the full multisite section of your wp-config?

Hi Mika,

define('WP_ALLOW_REPAIR', 'true');
define('WP_ALLOW_MULTISITE', 'true');
//define('MULTISITE', true);
define('DOMAIN_CURRENT_SITE', 'example.tld' );
define('PATH_CURRENT_SITE', '/' );
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
define('SUBDOMAIN_INSTALL', 'true');

Well.. Okay so your site died when you ran a plugin to get rid of MS files.

What plugin? Where did you get it? Please link to it.

Also keep in mind, your site was OLD. Old old old. So the plugin may not know how to tell it’s Multisitie, and you may HAVE to do it manually.

Didn’t say that. The plugin said that “Multisite wasn’t running” and IT died, because it was looking for “define(‘MULTISITE’, true);” in the config file. It doesn’t kill the site–it just doesn’t run because the test failed. That’s all and is essentially irrelevant; except for the fact that it pointed out that this upgrade through WPMU > 3.0 > 3.4.2 > 3.5 somehow didn’t get completely done–because:

The one install dies when I enable:

define('MULTISITE', true);

…plugins enabled or not.

That line is supposed to be in there.

What I’m looking to learn is what needs to be changed, where, in the first install to allow it to run as the second install does.

I’ll deal with moving attachments from /blogs.dir to /uploads separately; even if I have to do it manually like you did. I need to get this Multisite install running as a fully configured Multisite first.

Sorry, I misread that.

Generally we tell people to skip one release (so 3.0 to 3.2 to 3.4) but I don’t think that’s the issue here…WPMU to Multisite was tricky in the 3.0 days, and it’s been a couple years since most of us did it, so … Yeah.

Makes backup, and then run the repair, but I think it’s because WPMU saved the first site tables as wp_1_ and Multisite does it as wp_

You absolutely sure you removed all the WPMU calls from wp-config? Like the VHOST call and all?

Makes backup, and then run the repair, but I think it’s because WPMU saved the first site tables as wp_1_ and Multisite does it as wp_

Just checked and that format is indeed the case. Sooooo, do I manually change the first site tables to remove the “1_” or trust the repair to do it?

You absolutely sure you removed all the WPMU calls from wp-config? Like the VHOST call and all?

VHOST is long gone, replaced with SUBDOMAIN_INSTALL. Unsure of what else is WPMU-specific.

OH!

Do you have define( 'WP_ALLOW_MULTISITE', true );

I’ve cleared the problem.

• Backed up the database.
• Made an all-in-one wp-config (in place of the split one) and put it in WP root; just to be sure there wouldn’t be any confusion.
• Disabled all plugins.
• Nuked all of the core files.
• Uploaded fresh.
• Uncommented ‘define(‘MULTISITE’, true);’
• Refreshed the Admin page.
• Got the “Repair Database” error.
• Hit the link.
• Got “Error Connecting to Database”.
• Database repair did not change the main site table names.
• Figuring that 3.5+ Multisite needs the “non-1” blog_ID table names to identify properly, went into the database and renamed the main blog tables; removing the “1_”.
• Refreshed the Admin page.
• Sites came back up.
• Backed up the database again.
• Removed the now-redundant and depreciated ‘define(‘WP_ALLOW_MULTISITE’, true);’
• Performed search and replace on [prefix]_posts and all [prefix]_[blogID]_posts tables in post_content, post_excerpt and guid; replacing “files/” with “wp-content/uploads/sites/[sitenum]/”.
• Images in posts loaded from the new location but Featured Images (Post Thumbnails) were AWOL. “files/” was still in the path but all of the instances of it had been replaced in the sub-blogs. Something else is controlling this.
• Checked the database for “ms_files_rewriting” in _sitemeta table. Missing. Added it on an unused meta_id and set it’s value to “0”.
• Some Featured Images were still not loading. Was getting the “/sites/[sitenum]/sites/[sitenum]/” path. This took many change/test cycles to sort out but finally just emptied the upload_path, upload_url_path and fileupload_url fields in all of the _options tables.
• Featured Images (Post Thumbnails) came back on all sub-blogs.
• Sitewide Tags Blog was an oddity, with only a few Featured Images showing. No real pattern evident.
• I had missed the main site _posts table in the first S/R. Thought that it would be easier to just trash all of the posts and re-import from all blogs. That would refresh them all; having the other S/R operations already done on the sub-blog posts. Instead, got a PHP error saying: “WP_error cannot have an array on line 195 of sitewide-tags.php”. Good thing I didn’t empty the trash!
• Restored all tags posts and another set of S/R runs cured most of the missing Thumbs, but some of the URLs were relative, so not an easy way to separate by query. Got most of them by carefully choosing the search order, but the rest had to be done manually.
• Put the original split wp-config files back in place.
• Backed up the database again.
• Took all night, a lot of research, a lot of looking through the database and a lot of consideration on what not to do, what to do and in what order.

IT WORKS!

But wait, there’s more!

Just found a bunch of Custom Fields in the _postmeta table, meta_value column that needed a S/R for “files/” > ‘wp-content/uploads/sites/[sitenum]/

Could be wrong but I think that’s about it.