How to Use WPSiteSync for Content

Definitions:

First, let’s discuss a few terms that are used through the WPSiteSync for Content plugin.

  • Source – The Source is the web site that you would like to move data from. Often times this is a local development environment or a staging server.
  • Target – The Target site is the web site that you are moving the data to. If you want to move data between a local environment and a Staging environment, the Target is the Staging server. If you are moving data between a Staging server and the Live server, the Live server is the Target.
    • Note that you can set up a “chain” of Source and Target servers in order to move Content from a Local environment, to a Staging server to the Live server. Each step in the chain has a Source and a Target. When moving from Local to Staging, the Local is the Source and Staging is the Target. When moving from Staging to Live, the Staging is the Source and the Live is the Target.
    • You can have as many “links” in your “chain” as you like, moving Content one step at a time from the Source to the Target until it reaches the desired location.
      Content – This is the page or post that you are moving from the Source to the Target.
  • Push – This describes moving data from the Source to the Target, pushing the data to the Target server.
  • Pull – This describes moving data from the Target to the Source, pulling the Content from the Target server to the Local Server.
  • Staging – A Staging server is used to perform testing on before installing your code or data onto the Live or Production site. Here, you can test the behavior of code changes, test new plugins in a “sandbox” that is not normally viewable to the public. We highly recommend the use of a Staging server, especially if you’re working with a larger team or need to approve Content before it goes live. And using WPSiteSync for Content makes this process easy.
  • Live – The Live site is the site that is viewed and used by the public and your customers. This is also called a “Production” server. The terms are interchangable but we use the term “Live”.

Installation:

Each WordPress web site that you want to move data from (the Source) or to (the Target) needs to have WPSiteSync installed. The same version of WPSiteSync is installed, whether the site is to be a Source or a Target.

To install WPSiteSync for Content, go to your Plugins -> Add New page. Here, you can enter the search phrase “WPSiteSync” to look in the WordPress plugin repository for the plugin. Click on the “Install” button in the plugin search results to install the plugin. Once installed, you will be asked if you would like to activate the plugin. Click on the activation link to activate WPSiteSync for Content on the site.

Configuration:

The next step is to configure WPSiteSync for Content. WPSiteSync only needs to be configured on the Source site. What you’re doing here is configuring the plugin and describing where the Content is going to be Sync’d to. The Target site does not need to be configured unless it is also going to be Pushing Content to another Target site in the chain. The last link in the chain (whether there are two links or five) requires no configuration since the Content will not be Pushed to another site.

To configure WPSiteSync for Content, go to the “Settings” -> “WPSiteSync for Content” page. You will see the following options:
sync_docs_settings

Here you can configure the following items:

  • Host name of Target – This is the url of the web site that the Content will be Pushed to. So if you’re working on a local development environment and wish to send Content to your Staging server, enter the url of the Staging site here. Examples of this are http://staging.domain.com or http://mytestsite.com.
  • Username on Target – This is the login id of a user on the Target site that has “author” privileges or more. So an Author, Editor or Administrator is required here in order to create and update the Content on the Target site.
  • Password on Target – This is the password for the Username that you are going to be authenticating with. The password is not stored as part of your configuration, but it is required in order to Configure WPSiteSync for Content and allow communication between the Source and the Target. Once configured, the password field is intended to be left blank unless you are changing the password in your configuration. When the Username and Password are configured, you’ll see a green checkmark next to the Password field. This indicates that the credentials are working. If you see a red “X” next to the Password field, the configuration is incorrect or incomplete and you will need to change the Username and/or Password in order to get the correct settings saved.
  • Strict Mode – This is used to change the behavior of WPSiteSync. Strict mode means that, when you are Pushing or Pulling data you only want to perform these operations when the WordPress Versions and WPSiteSync for Content versions are the same. This is provided for data integrity purposes, in case there is a new feature added to either WordPress or WPSiteSync for content that will not allow reliable Synchronizing of data. In most cases this can be disabled, which is the default setting.
  • Remove Settings and Tables on Deactivation – You can choose to have WPSiteSync completely remove itself, including all stored configuration settings and database tables. Use this if you decide to no longer use WPSiteSync for Content.

Below the settings information, you will see a message that looks something like: “WPSiteSync for Content Site key: 8b06983e8750d11d0a3556813c77b37a” This is for debugging and/or support purposes. The Site Key is a unique identifier of your Source install to help WPSiteSync for Content identify where Content is coming from when performing Push and Pull operations. For the most part, it’s not need but is included here in case you need support and our developers need to track down an issue.

Using WPSiteSync for Content:

Once configured you can start using WPSiteSync for Content to move Content to your Target site. To do this, start editing some content. Go to a Page or a Post that you would like to move between sites. Once you have saved the post as either a Draft or Published, you will see the WPSiteSync for Content metabox in the upper right corner of the page, as seen here:
sync_docs_editor

Clicking on the details sync_docs_details button will show more detailed information on the Post if you’ve already Pushed it to the Target site:

sync_docs_details_panel
The details show the Post ID that is used for the Content on the Target site. If you’re Pushing Content that does not exist yet on the Target site, it will create a new post on the Target. Once Pushed, it will continue to use the Post ID on the Target even if you change the post title, Category or other information. When you do Push content the first time, WPSiteSync for Content will attempt to find an existing post with the same name on the Target and Synchronize with that Post Id. This is to avoid duplicate urls like “my-content’ and “my-content-2” on the Target site.

Pushing Content to your Target Site:

Once you’re ready to Push your Content your Target site, you can click on the “Push to Target” button. You’ll see an animation on the page indicating that WPSiteSync for Content is working on the Push request, as seen here:

sync_docs_syncing
Once the Push operation is complete, you will see a confirmation message or an error message letting you know the results of the Synchronization operation:

sync_docs_synced
Once you see a success message as shown above, your Content has been Pushed to the Target site. You can now view the Content there a confirm the operation as you like.

What has Been Pushed to the Target?

The Push operation will move all the information associated with the current Post or Page you are editing. So what’s included in “all the information”? WPSiteSync for Content will find all information that is stored in the database for a standard WordPress install. This includes the Content, the last modified time, the post status (Draft, Published, etc.) the post password (if set), the Featured Image, any taxonomy information (such as Categories and Tags), plus any “meta data” associated with the post. Meta data can include the “Custom Fields” section on the post edit page as well as information stored using tools such as Advanced Custom Fields.

If you add or remove Tags and Categories from a post, or change the Featured Image, the next time you Push the Content to your Target, these updates will be moved. WPSiteSync will remove tags on the Target that were removed on the Source. Same with Categories and the Featured image. In short, the Push operation ensures that the data on the Target now looks like the same Content that you have on the Source.

What is not Pushed to the Target?

WPSiteSync for Content will only Push the current Contents that you are editing within the Post Editor page. If you’re Pushing your “contact us” page, it will not be Pushing the “about us” page at the same time. It only Pushes the one piece of Content that you’re working on giving you precise control on what is being transferred.

Why Can’t I Push to my Local Development Environment?

The main reason for this is DNS. The Domain Name System is used to associate a public domain name like “mysite.com” with the IP address of your hosting service. You probably do not have a domain name set up with DNS for your local development environment. Even if you did, many ISPs block requests from “outside the network” to servers within the network for security reasons. That is what hosting companies are for. To do this, you would have to set up a DNS entry, allow routing from outside the ISP network to your development site, setup firewall and routing rules and then harden your development environment to protect it against malicious attacks and hackers.

Since most users are not going to go to these lengths, we have created the WPSiteSync Pull add-on that allows Pulling Content from your Target site to your local environment, rather than Pushing Content from your Staging or Live server to your local environment.

More about the WPSiteSync Pull in the documentation for that add-on.

Why is WPSiteSync missing Some of my Data?

So WPSiteSync moves everything. That’s great, but it’s missing some of my custom information. Why is that?

WPSiteSync for Content knows about and understands the standard WordPress database schema. If you’re using a plugin or custom code that stores data in a non-standard way, such as a custom database table, WPSiteSync will not move this data because it doesn’t know about the custom database table.

Plugins like WooCommerce, BuddyPress and Learn Dash and many others have lots of database tables that store custom information associated with the Content. If you’re using one of these plugins, you will require an add-on plugin for WPSiteSync that understands all the complexities of how WooCommerce, BuddyPress, etc. stores data in order to properly Push that content.

What Extensions are Coming for WPSiteSync?

Some extensions that are coming soon for WPSiteSync for Content:

  • WPSiteSync Pull – This plugin will allow you to move data from your Target Site to your Source Site.
  • WPSiteSync for Custom Post Types – This will add Custom Post Types and Custom Taxonomies to the types of Content that WPSiteSync for Content will Push.
  • WPSiteSync Authors – This extension allows you to select which Author on the Target site you want to assign as the post author of the Content you are Pushing.
  • WPSiteSync for Comments – The add-on will include Comment data and Comment meta data associated with the Content that you are Pushing and Pulling. This makes it easy to edit Comment information (including deleting spam and approving Comments) between your Source and Target sites.

We are also working hard on extensions for more complex data types, such as WooCommerce, BuddyPress and LearnDash. If there is a plugin that you rely on that extends the normal WordPress database schema and WPSiteSync for Content doesn’t currently synchronize all of the data correctly, we’d love to hear about it. We want to add as much functionality to WPSiteSync for Content as we can so hearing from you on what’s needed will help define the roadmap for WPSiteSync’s near future.

Being the Product Architect at ServerPress, LLC, Dave brings 35+ years of experience bridging traditional architecture with innovative Workflow solutions. Creator of WPSiteSync, among many other products, he loves pushing technology to the limit. His motto: No coffee. No code.