Question how to use Staging WooCommerce site correctly?

[larryk]

Server operating system version

CentOS Linux 7.9.2009 (Core)

Plesk version and microupdate number

Plesk Obsidian 18.0.47 Update #3

Just confirming or please correct my thinking... or even better, is there a step by step process documenting using clone to stage and update from stage for WP WooCommerce site?

1) clone the existing WC site
2) update or do whatever changes you need to the site
3) days/weeks have gone by, so do not want to overwrite certain DB tables (ie. losing current customers and orders, etc)
4) so you then update live from staging.... BUT how to prevent copying the WC tables you do NOT want to copy?

thanks

 

[larryk]

bump?
Has anyone done this successfully? Which tables to NOT overwrite on live?
thanks

 

[Bitpalast]

I understand that you have a production website with lots of customer and transaction data on sales, but you also have a staging website for design changes or other updates, e.g. in some plugin settings. Now as you have made the design changes you want to clone the staging to the production website, but this would also copy the staging data of WooCommerce to the production website, because cloning creates a full copy of the site.

As far as I know there is currently no feature that excludes the tables that are owned by a certain plugin from a Wordpress clone. Could this be worth a feature request on Feature Suggestions: Top (2146 ideas) – Your Ideas for Plesk ? Currently there seems to be none.

 

[Peter Debik]

A Uservoice request for this feature is now available. Please vote for it if you believe that this feature is important:

WooCommerce Staging Process (cloning without overwriting Woocommerce content)

WooCommerce = at least 1/3 of ALL e-commerce websites use WooCommerce. Can Plesk please make a process that works EASY for people to do the following on a WP and WooCommerce site: Live site > Clone to Stage site > Copy to Live site The issue is customers, orders, and products on the Live site...

plesk.uservoice.com

 

[trialotto]

@larryk, @Bitpalast, @Peter Debik

There is (or was) an excellent WordPress plugin for this particular "challenge", but that plugin is not maintained ...... and even though maintenance is not really necessary, it is not recommended to use that plugin anymore.

Nevertheless, the PHP code of that plugin could be easily used and updated to achieve the goal and realize the feature request.

In addition, it has to be mentioned that I have done considerable testing on the some topic ..... but in a far away past.

The conclusions - as far as I can recall them now - were :

a - use the WP plugin with the name WP Sync DB, with push and pull functions and a separate plugin for WP media files,

b - standard tools like Site Import and Migration Manager work fine, as long as databases are excluded in the transfer - WP Sync DB is better!

c - rsync works fine, as long as there is no necessity to import data from a database,

d - all other WP plugins are rubbish and dangerous .......


In short, yes, it is a feasible feature request and the code is already out there and for grabs.

Any talented PHP developer out here?

Kind regards....

 

[trialotto]

Just confirming or please correct my thinking... or even better, is there a step by step process documenting using clone to stage and update from stage for WP WooCommerce site?

1) clone the existing WC site
2) update or do whatever changes you need to the site
3) days/weeks have gone by, so do not want to overwrite certain DB tables (ie. losing current customers and orders, etc)
4) so you then update live from staging.... BUT how to prevent copying the WC tables you do NOT want to copy?

thanks

@larryk

In essence, it is highly recommended - at least for the time being - that you (in chronological order)

1 - create a child theme on the staging site,

2 - make all customizations persistent by adding them to the child theme,

3 - install and test plugins on the staging site,

4 - make a backup of the production site before transferring data of the staging site,

5 - rsync the child theme to the production site,

6 - activate the child theme whenever needed or desired,

7 - make a backup of the production site if the child theme can be succesfully activated - if the child theme requires alterations, revert back to the old theme,

8 - rsync the plugins to the production site,

9 - activate the plugins one-by-one and check the functionality,

and that should be all - in 97 out of 100 cases - in order to prevent that (database) data is overwritten when transferring to the production site.

The 3 other cases are :

10 - migration of media files : in most cases, one needs to use some kind of plugin (read: use it once and disable and remove it afterwards)

11 - migration of database data that has been altered by WP or a plugin : this essentially requires a much more elaborate process... send me a message!

12 - all other scenario's : this does not happen a lot, so I will skip this.


I must admit that all of the above can be labor intensive, but that is good : it gives you full control over what happens and enough time to intervene in case something happens that is not desirable (and that often happens, it is WordPress).

Then again, if you want a more easy method and if you are adventurous, then do not hesitate to try out Site Import or Migration Manager - surprisingly, it worked for me in the far away past.


Kind regards.....

 

[larryk]

thanks... I also saw this:

Skip WooCommerce Orders and Products

When you update or push to / from the staging site to the live site you need to make sure that WooCommerce Orders, WordPress users and products on the live site are not affected.

wp-staging.com