Best process for multisite local to staging to production

Hi!

I’m currently testing a multisite on my local testing environment (using Local) and hope to test on staging before going to production.

What is the best way to do this?

Do I have to (for example):

1. Make my hosted site multisite then copy it to staging, then

2. Use Shipper to copy the local multisite to staging, then 

3. (after testing) Push staging to production?

Why I’m doing this is because I’m switching from WPML (for site translation) to MultilingualPress, which puts each language in its own site in a multisite.

(Making this public in case someone else is/has been doing this.)

Thanks!

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Thanks Kris !
    Actually my first question is about what I should do first. :smiley:
    My hosted site is not multisite right now.
    If my goal is to go local > staging > production with a new multisite setup, do I have to make production and staging multisite first?
    I suspect I do, but I wanted to check.
    Another way to put it: Can Shipper export a multisite (local) to a non-multisite (staging)?
    Thanks!

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Hmm…
    Looks like this part of the Shipper documentation answers part of my question:

    Multisite check (Shipper does not export multisite to single or single to multisite)

    So I guess my staging site (and therefore my production site) needs to be converted to multisite before Shipper can export my local multisite to the staging site…

  • Kris Tomczyk
    • Ex Staff

    Hi Chris

    This will be the tricky part, as you have already set up a primary domain for that temp site and the site seems to be live.

    I will recommend those steps:
    1. on localhost site, for main domain set up coming soon mode
    2. on the WPMU DEV site, for main domain set up coming soon mode as well
    3. on the WPMU DEV side, make a full site manual backup in HUB before the next steps
    4. on the WPMU DEV side, switch single to multisite
    https://wpmudev.com/docs/hosting/tools-features/#multisite

    At this point, the localhost site and WPMU DEV site are equal, when it comes to the installation.
    Please note both main sites should be the same when it comes to content, as you want to disable coming soon mode as soon this possible after migration.

    5. use Shipper to migrate the site.
    6. disable coming soon mode on the main domain

    Additional future steps:
    7. set up staging and make some changes, add new content, new subsites, etc.
    8. push changes from staging to live.

    As a side note, we offer for free help with migration, but that works only for cases where we have access to site or at least ZIP of site and exported database:
    https://wpmudev.com/docs/hosting/overview/#manual-migration-by-wpmu-dev-staff

    Kind Regards,
    Kris

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Thanks Kris !
    So I assume my first idea of local > staging > production isn’t going to work, and what I need to do is local > production. Fair enough!
    I’ll need to do a bit more work on the local site to make it ready to go, and then follow the steps you outlined.
    What I’m trying to do here is a bit unusual I guess: I’m not really migrating a site, but making a fundamental change in how the existing site handles its content. I suppose that practically means I’m replacing the existing site with a new one, although to visitors it should all look the same once I’m done.
    I’ll report back on how it all worked out.
    Thanks again!

  • Kris Tomczyk
    • Ex Staff

    Another solution comes to my mind when it comes to “local > staging > production”.

    1. Keep the current WPMU DEV live site as it is
    2. Make WPMU DEV live site multisite
    3. Push live site to fresh staging
    4. Switch local to multisite as well
    5. On local and staging install the same plugins (correct plugins enabled in the network and on the main site)
    6. Use default WP core -> Tools export and import from local to staging
    7. If all changes done on staging make a manual backup in HUB and push changes from staging to live

    Kris

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Thanks Kris !
    That sounds promising. I’ll give that approach a try and see how it goes.
    It’d be great to finish my testing on staging before going live, so this looks good.
    With lots of backups along the way! :wink:
    I’ll report back on how it goes.
    Thanks again!

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Hi Kris !

    Sorry to take so long updating this. It’s been a busy month.

    I had no problem converting my production site to multisite. That was great!

    Then I pushed the live site to staging, and had a bad idea. Hey, I thought, why not use a Shipper package migration to migrate my local site to staging? It seemed to have gone well, until I discovered that the links on my live site were pointing to staging… I’m assuming that something in the migration did something to the database for the live site as well as staging. Do live sites and staging sites share a database but with different tables? Anyway, I learned: do NOT try to migrate a local site to a staging site using a Shipper package migration.

    Or maybe I should have just given the migrated database tables a different prefix?

    Fortunately, restoring from backup at the Hub is easy and effective!

    Ultimately I ended up using the first approach you suggested: using a Shipper migration from local testing to the live site. It predicted it would take 1 hour 38 minutes but actually took 3 hours. But it worked! Now I’m all done with the migration!

    I’m still working on a few odd things, but the migration is done. Thanks for your help! :tada:

  • Mhamdi Youssef
    • Support Agent

    Hello Chris Ryal !

    Hope you are doing well!

    I’m happy that you are all setup now, and your site is running well :blush: regarding your question:

    Do live sites and staging sites share a database, but with different tables?

    Staging uses an incremental clone of your Production file system. This means that it normally uses very little of your storage space. Only new/changed files on Staging or deleted files on Production will increase the amount of storage used by Staging and doing a fresh sync from Production will reset that to zero again.
    That being said, when you migrate your new site to staging site, this means that everything will be overridden and hence, you will have a separate install on your staging site.

    Furthermore, it is very common to have permalinks issues when you migrate your site to a new server, we usually do a Search and Replace for our members and their sites works just fine. However, since all looks good now, we are happy for you :blush:

    Please let us know if you need any further help!

    Kind regards,
    Youssef

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Thanks Mhamdi Youssef ! That’s good to know.

    Regarding the database, I’ve just been having a look (should’ve done that before! :sweat_smile:), and it seems that live and staging do share the same database but with difference table prefixes.

    What I messed up in trying to migrate with a Shipper package had to do with the database tables (I think). Shipper found that the destination database had tables with the same prefix as the one I was trying to migrate and (of course) offered me the option of modifying it. But I didn’t, and that (I think) turned out to be my problem.

    To be clear about it, the default WordPress prefix is usually wp_, and it seems that the staging site becomes wp_2_. I was trying to migrate a site with a database prefix of wp_, and I guess I should’ve told Shipper to use wp_2_. Instead I allowed Shipper to overwrite wp_, which messed up my live site. Oops! In retrospect it all seems clear… :rolling_eyes:

    I had assumed that ‘separate install’ meant ‘separate databases’, but in fact it seems to mean ‘separate database tables’. Which makes perfect sense now!

    I hope that made sense! :confused:

  • Nithin Ramdas
    • Support Wizard

    Hi Chris Ryal ,

    I had assumed that ‘separate install’ meant ‘separate databases’, but in fact it seems to mean ‘separate database tables’. Which makes perfect sense now!

    It’s the destination URL that would be different rest of the table names and the database name would be identical in general when compared to live and staging.

    That’s the URL for staging would be:
    nishigawakobo.staging.tempurl.host

    I could notice what you have stated in your staging. However, that shouldn’t be the case. In general, the staging database name and table name should be identical to the live site.

    In your staging, the table has different prefixes when compared to live. Is it possible to delete the staging and create a new staging and see whether that creates the creates staging with identical table names correctly?

    In general, as long you are running the shipper installer file(installer.php) under the following path, ie:
    nishigawakobo.staging.tempurl.host/installer.php

    Then the migration wizard will be picking the database and table prefix from the staging database.

    Kind Regards,
    Nithin

  • Chris Ryal
    • Nishigawa Kobo webmaster

    Thanks Nithin !

    Well, this is odd, but I’ve had a look at the live and staging databases just now, and they are indeed at separate URLs and have the same table prefixes, as you mentioned.

    Actually what I’m seeing is that if I click on the home icon in phpMyAdmin I see tables with the wp_2_ prefix in both staging and live, but if I click on the database structure link (‘here’ in the screenshot), I can see that both databases also have a full set of tables with a wp_ prefix.

    [attachments are only viewable by logged-in members]

    I think this has happened because I was cautious when I migrated from local testing to production using Shipper (API) and told it to rename existing tables.

    So now I have a whole set of redundant tables… :anguished:

    Can you suggest how I might clean this up?

    Thanks!

  • Mhamdi Youssef
    • Support Agent

    Hello Chris Ryal !

    Hope you are doing well!

    I double-checked your DB and after I knew that you have a multisite, I can assure you that nothing is wrong with your DB, the Good thing is that you only have 1 DB Prefix (wp_) the prefix (wp_2_) is for your subsite, if you get more subsites you will end up with more sub-prefixes like (wp_2_, wp_3_, wp_4_ etc… )

    Here is an example from my test site:
    [attachments are only viewable by logged-in members]

    If we check each _options table, you would notice that it holds different siteurl/home URLs for your subsites.

    Therefore, you don’t need to make any changes to your DB or to clean it or to reconfigure it.

    I hope this helps!

    Let us know if you need any further help!

    Kind regards,
    Youssef