You define per entity type (like a Page, an Image or a Menu Item) how you want to pull it. The following is available per type:
Besides pulling automatically or manually, the third option is to pull referenced content, meaning that this content is only pulled if it’s used somewhere else. This is useful for paragraphs and bricks for example. Depending on your desired workflow, it can also be useful for taxonomy terms, menu items or media elements. You can even use it to pull referenced nodes along with the main node.
Pull from Pools
Select what Pools you want to pull the given entity type from. You have the following options per Pool:
Forbid: Ignore this Pool; this Flow will never pull content of this type from the given Pool.
Allow: Use this when configuring to Pull Content Manually.
Force: Use this when configuring to Pull Content Automatically.
By default, Content Sync will not only distribute creating or updating content items but also deletions of content meaning that if you delete content on the source site where you first created it, the content will also be deleted on all the subscribing sites that pulled it. This option allows you to disable this default behaviour.
Please note that you need to both enable Push deletions on the publishing site and Pull deletions on the subscribing sites for deletions to come through.
By default, you can still delete content locally after it has been pulled from a remote site. In some cases however, especially for Content Staging, you may want content that has been pulled from another site to never be deleted on the pulling site manually- instead, the content should only be deleted when it’s deleted on the source site (see above). There’s another option available for such behaviour: Allow deletion of pulled content.
Content Sync provides you a couple of different options when it comes to handling updates of content from the source site that are pulled into this site:
Dismiss local changes: Editors can make changes to content that has been pulled from a remote site. If the remote site pushes an update however, all local changes will be lost. Not recommended for most people as this can be confusing for editors.
Ignore updates completely: After a content item has been pulled, it will never be updated from changes on the source site and is completely decoupled. You can make any changes locally and they will persist.
Forbid local changes and update: Don’t allow editors to make any changes on content that was pulled from another site. Recommended for content staging and a general master-slave approach.
Update unless overridden locally: The best of both worlds. By default, changes from the source site will be pulled and replace the outdated content on the site. However, editors can explicitly override content to customize it- in this case the flagged content won’t be updated by remote changes and local changes will persist. See here for more details: Override content locally.
Create unpublished revisions: Only available for node bundles that are configured to create new revisions on every update. If set, pulled updates will always create a new unpublished revision, allowing your editors to review all changes per site before publishing them. You can use Drupal’s built-in and customizable review processes just as you would with locally created content.
Type and Field: File
Files are syndicated along with their file contents, so they are an exact replica as on the source site. If you don’t want to syndicate the same file to save storage, we recommend you use a CDN or DAM tool to manage these assets.
Type: Menu items
By default, only menu items that are enabled will be pulled by Content Sync. You can use this option to also syndicate menu items that are disabled.
Restrict to menus
By default, Content Sync will distribute all menu items from all menus. You can use this option to only syndicate menu items from specific menus.
Type: Node (Content)
By default, unpublished content won’t be pulled by Content Sync. This is based on revisions in Drupal, so as long as a revision isn’t published, it won’t be syndicated. There’s one special use case however that we also support and that is to Explicitly unpublish content. So if you completely unpublish a content item, you usually want the Unpublished status to still be syndicated to your remote sites, so to unpublish it on all sites.
You can overwrite both of these settings per node type.
Type: Taxonomy term
By default, Content Sync matches content based on their UUID which is a globally unique ID that is created along with any entity whenever it’s created. In some cases you may not want to distribute all taxonomy terms however and still be able to syndicate them when used in pulled content without having to deal with duplicates. In this case you can simply check the Map by name option in the taxonomy term settings. Please note that this will not work on the Subscribe only to filter mentioned below.
Field: Taxonomy term reference
Content Sync provides you Pools to divide your content and distribute it to different sites based on these Pools. If you need more flexibility or you are already using taxonomy terms to tag and categorize your content, you can use the Subscribe only to pull option per taxonomy term reference field to limit what a specific site should import. Only content that has the given terms assigned will be pulled. This works both for manually and for automatically pulling content. If you are pulling content manually, the Pull Dashboard will also not show items that don’t match this filter.
Field: User reference
As mentioned here we don’t syndicate user accounts. We do syndicate user references however. So if the same user exists on both the publishing and the subscribing sites that either has the same email address or the same user name, we will assign the user accordingly on the subscribing site as well. You can configure whether to use the user name or email address for matching.