Best practices for using staging site for updating live woocommerce site

Hi,

I have a live woocommerce site, that I need to update/change without losing or overwriting live data?
I made a staging site to do this,

  • but what are the best practices to do this?
  • which database tables to exclude?
  • other points to be aware off?

thanks

No can do. Cloudways needs to make it so that you can specify custom post types to exclude instead of only allowing you to choose which table to move across.

2 Likes

There’s a tool called https://www.skyverge.com/link/wp-migrate-db that will allow you to do this.

SkyVerge, the devs of the tool, have written an in-depth tutorial here https://www.skyverge.com/blog/moving-woocommerce-orders-sites/

I’ve not done this process personally, but was pointed to it by an associate who had the exact same problem and the OP. She tried ALL the ways to address the issue, and said this was the only thing that saved her.

1 Like

thanks! It looks all quite complicated…
no simple solutions here?

Unfortunately, no. Since WooCommerce uses wp_posts, You’re bound to have collisions in the ID column. :frowning:

That’s bad news.
How do big woocommerce sites solve this problem?

They go through the complicated process, I guess.

Another solution would be to develop a new theme ON the live site and use an “admin only theme viewer” to see the real-time implications of what this new theme would mean for your site and then at cutover time, switch the theme for the customers.

I suppose you could also develop the theme on the staging site and then migrate the theme into the live site instead of pushing the entire staging site live. If you do it right, all the relevant files will be in wp-content/themes/your-new-theme/ and you just add the new theme (or replace the existing theme if you’re updating functionality instead of developing a new theme). This way, all the DB tables remain in real-time and you’re only modifying the customer-facing functionality.

If your new UX requires additional plugins, simply add them to the live site, activate, configure as on the staging site, and then deploy the new/updated theme as described in the previous paragraph.

1 Like

There are three ways of making changes on a website:

  1. Make the change on the live site.

  2. Make the changes on the staging site, when done, make the same changes on the live site.

  3. Clone the site. Make your changes. When done, migrate orders and everything else to the new site.

Use #1 when you feel safe in being able to make a change without breaking the site. All non-coding changes and small tweaks such as adding a code snippet to change the length of blog post excerpts can be done this way.

Use #2 when you need the safety of making sure your changes are not going to break the live site, or when you want to show your changes to the client for approval before applying them to the website.

Use #3 when building a brand new site.

Cloudways staging site feature is new within the last year, so hopefully in the future they’ll make it so that we can push data back without having to worry about overwriting orders and form submissions, but right now it is currently not possible to use staging sites this way.

If you want to experiment around, you can use https://github.com/liquidweb/woocommerce-custom-orders-table to put all of the orders in a separate table, and then you would be able to use Cloudway’s staging site feature to exempt the orders table and push everything else to the main site. When doing this you’ll want to make sure that a) you don’t have any other plugins such as a contact form plugin putting data into the default database tables instead of creating their own table, and b) make sure no one else is making any other changes when you work on the staging site as those changes would get overwritten.

1 Like