Overview
Flows control when and how what content should be pushed from or pulled into a site. You can create as many Flows as you like to support as many different workflows as needed. Any site can push and/or pull content and you're free to configure sites individually or share identical Flows between them.
Flows are managed in the Flows tab after you have registered your site.
If you don't want to share Flow configurations, you need to exclude them from the config management e.g. by using the config_ignore Drupal module- otherwise the config will be reset the next time you run a config import.
Reusability
Flows are standard Drupal config entities, so that your sitebuilders can easily export the configuration from one site and then import it onto another site so you don’t have to do the same configuration manually again and again.
Integrity checks
Our most important objective with Content Sync is consistency and to avoid broken content- we want everything to be exactly the same on subscribing sites as it was on the publishing sites. That’s why we document how every one of your content types is configured per site and make sure that before pulling a content item, all required fields were provided by the source site. For example if you have one target site that has a new required field Image description but it’s missing on the source site of your images, Content Sync will not import the content but instead put out a warning that there’s a configuration mismatch in your sites that needs to be addressed first. Optional fields are allowed to be empty or missing.
There’s a button available to site builders called Show version mismatches when editing content (and at the Sync Health site if you enabled the Sync Health submodule) that will point out the exact differences between the field configuration of entity types for all of your connected sites.
Extendability
We extend Content Sync with new functionality regularly, adding support for additional modules, content types and field types along the way.
We whitelist entity types and field types because we want to be 100% certain that all of the types that we want to support are supported with every release- that's why we run automated end-to-end tests for every single field type and every single entity type we support. If there’s anything you’re missing, do let us know! Adding an additional type typically only takes a couple of weeks. You can use the Compatibility tab in the admin area to check whether any field or entity types are not supported- if so, do reach out to us.
You can also develop your own serialization handlers per entity type and field type if you have created custom entity or field types you need to support. Checkout the custom field handler sub-module for an example.
The only thing we won’t syndicate are user accounts due to the negative impact on your site’s security. Please use Open Auth, LDAP or other technologies and modules to help with that. Content Sync will map user references by email and/or username - so as long as the same user exists on the target site as on the source site, it will be de-referenced accordingly.
Revisions
If your content type is enabled to create new revisions, Content Sync will do the same. So anytime an update is pulled from a remote site, a new revision is created. This allows you to quickly switch back to an older revision on all sites. You can also roll back to an older revision on the source site and then push that older revision to revert all sites at once.
Fields
By default, Content Sync will include all of your fields when pushing or pulling content. You can overwrite this per field to exclude fields whose content you don’t want to syndicate, e.g. if they’re site-specific, by creating a custom field handler (see Extendability above).