The problem scenario
I have come across many different scenarios and tickets where it would have been mighty helpful to be able to sync two WooCommerce sites. This is one of my favourite subjects so I try to keep tabs on various tools and also set aside time to test promising solutions.
Understanding the sync scenario for WordPress
So what do you need to do to actually sync to WorPress sites? In order to able to sync two WordPress / WooCommerce instances we need to basically sync two things.
- the /wp-content/ folder – a file sync job
- the complete database – a database sync job
As for number 1) syncing files remotely is relatively simple. Most modern FTP clients can do it fine and have the feature built in.
But: Conflict is always hard.
What is a conflict? When two files / two datasets have the exact same file name, things get difficult. You need to set a deciding factor, for example ‘newer date overwrites older date’.
However there must be one source of truth. What if two developers worked on the same file during the same time period? In that case files need to be merged first and then deployed. Someone has to take a look at both sides and merge the data in a way that still makes sense. This often requires two- and three-way comparison of both files. There are of course tools for this, here are two examples: http://meldmerge.org/ for Linux and a free online tool: http://www.mergely.com/ – I google for “diff merge” to find these.
Merging needs to be done before and in person. And I have yet to see anything that can recognise and handle this complicated process during a file sync procedure.
Where does WooCommerce store it’s data
WooCommerce tries to stay as extendable and compatible as possible. You can glimpse at our coding principles here:
Specifically this is something you should remember: https://docs.woocommerce.com/document/create-a-plugin/#section-6 – custom database tables structures are to be avoided. In short this means the following.
- WooCommerce Orders and Products are custom post types and stored in the
- All relevant order and product data is stored as meta info via custom fields and saved in the
wp_postmetaor saved as options via
The database sync trouble
The way I understand it, the problem with keeping track of WordPress database changes is the
post_ID. As content is added and both sites modified the hierarchy and order of the
post_IDs can develop in different ways.
This means that very quickly two sites who seem identical now have different information in posts with the same ID – hope this last bit made sense so far. If not, please let me know in the comments.
So how do you tell what is the source of truth? You cannot really. In that case you would have to write one of the data-sets anew with a different ID. Think of when you copy files on your computer and are asked what to do as identical files names are encountered: When selecting “Copy and keep both files”, your computer appends a ‘-1’ to the file and copies the data over. This would also work well here in a sense that no data is lost.
In the case of database entries however, this breaks the dependencies: for example the link to the user, the corresponding order etc. all this information gets unhinged since the post_ID changes.
When merging you have to account for all these scenarios.
So yeah, merging is uber, mega, final-boss-level difficult.
My tools overview for tackling WooCommerce sync
I have tried many tools, only one does live up to the job thus far.
Lets start with the winner.
Commercial Plugin: WP-Stagecoach
WP-stagecoach works from my experience and successfully merges a staging and production site. I did test it briefly, but did not test thoroughly with WooCommerce yet. The drawback is that you do not own the staging site. The staging site data is kept on their server.
However they are working on this:
WordPress Plugin: Database Sync
I have not tested this yet.
The description reads “can pull or push the entire database between servers with just a click”.
I expect it to ‘just’ do a full database push and pull.
GitHub Plugin: Versionpress
Versionpress is based on Git.
They have a very good blog article that explains the process of merging and it’s challenges: https://blog.versionpress.net/2015/09/versionpress-2-0-staging/
WordPress plugin (with commercial Pro version): WP DB Migrate Pro.
I use the Pro version for providing test systems for customers in my WooCommerce tickets.
WP DB Migrate Pro works smoothly and well. It allows you to selectively push and pull database data by tables. But there is no sync functionality available. Deliciousbrains are working on another solution they call ‘datahawk’.
WordPress plugin: WP-staging
Fastest site duplication I know of. It duplicates locally which is a big plus as you stay in the same environment. The developer is still working on a feature that allows you to push back changes.
WordPress plugin: WPSiteSync for Content
Briefly tested, no support for WooCommerce yet.
WordPress plugin: Gitium
I haven’t taken a look yet. Seems to cater to a different problem scenario.
WordPress plugin: WP Github Sync
I haven’t taken a look yet.
WordPress plugin: PushLive
I haven’t taken a look yet. This one supports WordPress Multisite.
Yes I also looked there. The only thing I found were two ‘copy’ plugins, but nothing capable of sync.
What is next?
Honestly I do not know. But I will keep my ear to the ground and post as soon as I have something new and viable.
Have I missed something out there? If yes, let me know in the comments.
While I was working on my staging site my live site got new orders, that I do not want to overwrite / lose.
How do I push my staging site to live without loosing new orders?
How do I selectively push my data so I maintain new orders?
As mentioned above WooCommerce uses no custom tables for storing products, customers and orders, but saves its data in the
wp_post table along with all other posts. There is no selective table transfer possible. You would have to identify the WooCommerce data amidst the post data and then magically and seamlessly fit it into your live site while preserving / adapting post IDs correctly. Not happening (for now).
The solution to this is to use an import / export routine in addition to your deploy process.
- Export all orders / customers / products / all WooCommerce data from your current live site. It does not have to be all the data, you can of course set a date range for the export.
- Shutdown / block live site to prevent further orders.
- Push staging onto live overwriting it completely
- Import data from step 1 to new live site.
This will result in a fully updated live site with all current WooCommerce data on board.