Copyright © Brave Digital 2018
Introducing WordSync

Introducing WordSync




In most development environments, it is standard practise to split your project into live, staging and development versions.

The coders work on the development version which is usually running locally on their machines. The client is able to view the staging version and suggest changes while the live version carries the most up-to-date content and is public facing.

In this setup, any updates to the code flow from the development version towards the live version and the content is usually added to the live version and this trickles down towards the development version.




Image credit: Open Concept

SaveOver the years, we at Brave have struggled with getting the WordPress CMS to fit within this paradigm. Pushing code up to a live version is easy but getting new content from live down to our development servers has proven difficult.

One option is to overwrite the development database with the live database. This is not only tedious but also introduces problems, such as the sites having differing URLs which need to be replaced, and perhaps sometimes we have the development install set up with testing-specific settings which we would like to keep. Doing a database overwrite meaning losing all users, settings and more when perhaps all we wanted was the live site’s posts, pages and images.

There have been a few commercial attempts at addressing this, however, none of the tools on offer have really hit the spot for us, and either had limiting restrictions, such as having to host our sites on a third party’s managed infrastructure, or the tool didn’t synchronise vital pieces of content that we needed.

So we decided to put a bit of time into building a WordPress plugin we could use to easily synchronise data and settings between WordPress installs. After a few months of development, early results are promising and we’ve decided to release this tool free to the greater internet.

That tool is WORDSYNC


What WordSync Offers

WordSync is a WordPress plugin that allows you to synchronise posts, pages, users, taxonomies, attachments and settings between two WordPress installs.

After setting up the link between the two sites using a secret key, you can perform a sync on the target site which will show all changes needed to bring its content in sync with the source site. You can select which of these changes you’d like to synchronise across and WordSync will synchronise just those changes that you’ve selected.

WordSync provides modular synchronisers which act on certain bits of data on your site:

  • Settings – syncs all WordPress settings and all plugin settings (for those plugins that store their settings in the wp_settings table)
  • Users – Creates, updates and deletes users so that they reflect the source site. New users will have to reset their passwords in order to login.
  • Posts – Synchronises ALL posts, including pages and all custom post types. Preserves post parent relationships
  • Taxonomies – Synchronises all taxonomy terms, but both sites need to have the same taxonomies defined. Ie. if the theme defines custom taxonomies, both sites must have the same theme active.
  • Attachments – Synchronises attachments. Attachment images are downloaded directly from the source site and then inserted into the media library and linked up to the same posts as in the source site.

You can choose which of these to activate before performing a sync but some rely on others to run first before they themselves are able to run. For example, in order to synchronise posts, the users first need to be synchronised so that post authors can be determined.



It’s free?

We have built a business around WordPress and benefitted greatly from the generous contributions of the many people involved. Thus we have made the decision to open-source and freely distribute WordSync. At the time of writing we are still waiting for submission into the WordPress plugin repo, but we have the project hosted on GitHub. Please feel free to download it, give it a try and perhaps even contribute to make WordSync even better!


Bear in mind that WordSync is still in alpha and modifies your site content. It may not always perform adequately and it would be strongly advisable to backup your site before using WordSync. WordSync does not yet offer a rollback option once your data has been synced. Brave Digital does not accept any responsibility for lost or corrupted data. Please use WordSync at your own risk.



How It Works

WordSync operates as a comparison and difference marking engine:

  • The WordSync plugin is installed on both the local and remote WordPress installs.
  • The local plugin establishes a connection to the remote plugin using the user-supplied URL and user-supplied secret key which needs to match the remote’s secret key which was also set up in a similar manner.
  • The local plugin checks its version, the WordPress version and the WordPress db_version and does not proceed unless they all match.
  • Individual smaller processors start up and process a small portion of the data. Each processor works in a similar way but tailored individually to the type of data being processed (posts, users, attachments, etc):
    • The processor gathers both local and remote data that it is interested in. This means the remote plugin tells its corresponding processor to start up and gather the remote install’s data and relay it back to the local plugin.
    • The data is split up into individual objects known as data items. Data items can be Posts or Pages or Categories or whatever objects need to be migrated between the installs. Each data item stores the properties of that data item which need to change. For example, a Post data item would have “post_title”, “author”, “last_modified” fields, amongst others.
    • The local install pre-processes each of these fields to perform any translation needed between the sites. For example all instances of the remote site’s URL are replaced with the local site’s URL.
    • Each processor defines which of the data item’s property fields should be used to uniquely identify this item and match them to the remote install’s data items. For example, Users are uniquely identified by their email address field, but Posts are indentified by a combination of their GUID field and the post title / slug.
    • The processor loops through all the local and remote data items and tries to match them up using the comparison fields above, adding them to a queue as it proceeds:
      • If the data item is local but cannot be matched to a remote data item it is Marked for Deletion.
      • If the data item does not appear locally but remote has it, it is marked To Be Created.
      • If the data item is successfully matched between local and remote, it is marked as Modified. The individual fields of that data item are analysed and determined if they need to be created, deleted or modified.
      • If the data item is successfully matched between local and remote but no fields are modified, this means that the data items are exactly equal and it is removed from the queue.
      • Once a processor has run through and matched all the local and remote data, a mapping can be drawn up between them. More on this later.
    • The user is then presented with the queue of data items which needs to be updated on the local install. A table is shown with the data items and a comparison of the original and new data, with highlights showing what has changed. The user can then select with checkboxes which data items should be updated and which should be ignored.
    • Once the user has selected appropriate actions for each data item, the queue is processed one data item at a time. This update process will vary with each processor, but at its most simple it means going through that data item’s fields and updating each to delete, create or modify to a new value.
    • Some processors rely on others to have run first. If a property is encountered that is a reference to another data item in the system, it will look up the processor responsible for that data and ask what it’s remote to local mapping is. For example, if a Page is being synced, one of its fields would be the Author ID of the page. These will need to be looked up in the Users processor’s data to see how the local and remote users map to the Author ID property of this page. For instance if the user “” is user ID 5 in the local install, but user ID 8 in the remote install, WordSync makes a mapping between them. Then when the Posts processor runs, it knows to set the Author ID field of Joe’s posts to 5 instead of 8.
    • Finally after all processors have run, both sets of data should now be in sync.




In closing

It is still early days for WordSync and we hope that it will be embraced by the WordPress community and will continue to grow and improve as time goes on. Please feel free to give it a try and even to contribute if you can!

Thank you.




Brave Enquiry
Hi there!

Before we kick off, we would like to get
to know you a little better.

* these fields are required

Great thanks,

Please tell us about your project:

Worried about keeping your idea safe?

No problem! Check out our standard NDA here and then select agree below to sign the NDA.

No problem! Tell us more about your .

What are you hoping to achieve with it? What is its purpose?

We need some more info…

Can you tell us more about your project?

Ok that's great!

Typically our website projects range from R150k - R750k depending on the project complexity.

Ok that's great!

Typically our app projects range from R350k - R1.5m depending on the project complexity.

Ok that's great!

Typically our custom solution projects range from R350k+ depending on the scope of the project.

Not sure? Not to worry...

Don't worry, we'll discover what you're looking for in no time.

Let’s talk budget

What would you say your budget range is?