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 content from for the Flow you configure.

Pull deletions

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 behavior.

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 behavior: Allow deletion of pulled content.


Pull updates

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:

  • Update and Forbid Editing: 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.

  • Allow local changes: 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.

  • Ignore all updates: 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.

  • Unrestricted: 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 and lead to data loss. If you want to use this, consider incorporating a cross-site content locking mechanism.


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

Ignore disabled

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.

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.