Support » Networking WordPress » Migrate 3.6 to actual 3.6

  • Resolved spherical


    OK, I’ve been through everything I can find over the past three days and not finding any definitive answers. Lots of speculation, outdated instructions and some amount of ambiguity, so coming to the Brain Trust before I Bork the whole darn thing.

    With the new direction that WP is taking, it seems a good idea to get everything into order, so that future updates/upgrades are compatible and work as well as possible. It is a sub-domain install, currently at 3.6.1, having upgraded from WPMU 2.x all through all versions since. The conversion to WP 3.0 went as expected, as did all others subsequent… I thought.

    What I didn’t do (because I just came across it TODAY (why?)) is to follow the upgrade instructions listed on this page:

    The current 3.5+ .htaccess is running, with the exception of having the ms-files.php line added in to rewrite the attachments location; which is what I want to get rid of.

    It started when I began to migrate the old /blogs.dir/ID/files/yyyy/mm/ to /uploads/sites/ID/yyyy/mm/

    I read Mika’s treatise on doing this, along with a few other accounts on the topic, and then came across a plugin to do it. Attempting to run the plug, it died, saying that my install isn’t Multisite. Uhhh… yes it is. Checking the plug code it barfed on the absence of:

    define(‘MULTISITE’, true)

    OK, added that in, attempt to login and get the ol’

    Error connecting to database

    If I’m logged in, and refresh the page, I get:

    One or more database tables are unavailable. The database may need to be repaired.

    Have yet to hit that repair link.

    Found a listing of tables that are in 3.4 and those all are there but can’t locate a listing of 3.5+, which would probably let me see what’s missing. I have a separate dev install where I test my plugin when new WP versions reach RC and it runs fine with define(‘MULTISITE’, true) in wp-config. It, however, only has one site, no secondaries.

    What do I need to do, short of doing a whole new install and exporting/importing, to clear this hurdle? I’d rather do this surgically, as opposed to nuking it from orbit.

    Thanks for any directions.

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


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    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');
    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    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.

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    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.

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep


    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.


    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.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Migrate 3.6 to actual 3.6’ is closed to new replies.