We provide some advanced options under the Advanced tab of the Content Sync admin UI:


Throttling

Content Sync is highly scalable- we can perform millions of updates per day on your site. But most Drupal sites won't be able to handle this load or it may lead to a poorer user experience for visitors. That's why we throttle requests from our service to your sites. You can customize this throttling to best fit your sites performance, required publishing throughput and allowed impact on user experience. We provide two throttling settings for this:

  • Requests per minute: How many updates we make per minute; this counter resets every minute. When the limit is reached, the message is added to the end of the request queue for this particular site. Queued requests are processed every 20-30 seconds.
  • Parallel requests: How many requests we are allowed to start in parallel. This only applies to queued messages that either reached the throttling limit per minute or that are retried from a previous failure. When our message cron runs every 20-30 seconds, it will only trigger this number of requests to your site and then wait for the next run.

You can adjust throttling per site and set a default that is used for all other sites in a space.


Performance

Individual requests per translation

By default, Content Sync will make one request for requesting and updating all translations of shared content. With this setting enabled, Content Sync will make one request per translation instead.

We will remove the option to only make one request with all translations in the future, so we recommend enabling this on all new installations.

This setting applies for all sites in a space.


Skip unchanged translations

By default, we request and update all translations for every push/pull we make. With this setting enabled, we will skip translations that haven't changed. Enabling this allows editors to individually select translations to push at the Push confirmation dialog.

We will remove the option to always request all translations in the future, so we recommend enabling this on all new installations.

This setting applies for all sites in a space.


Custom request timeout

By default, requests we make to your sites time out after 60 seconds. You can use this if your CDN, web server and PHP allow a higher timeout.

You can adjust throttling per site and set a default that is used for all other sites in a space.


Skip unchanged entities.

By default, we update all entities that are part of the content when we make an update request at a site. This allows us to recover from any potential previous failure or technical issue. Imagine there's a glitch e.g. with your cache and it's serving outdated content that we use as the base to make updates. If we only did delta updates, any problem at any point in time would carry on indefinitely even if the code or service was fixed. That's why by default we do full updates on all entities that are part of the content that's pulled into the site. But in some cases when you're working with hundreds of entities like very nested paragraphs, this can lead to performance bottlenecks and even timeouts. For those cases, we offer an Adaptive setting that will perform highly reliable updates by default and opt-in to optimized updates for the minority of content where it's needed. We recommend you use our defaults as a starting point after enabling this, but you can also customize the thresholds to run optimized updates:

  • Large entity count: When a content item includes more than this number of dependent updates, an optimized update will be performed.
  • Slow request duration: Content Sync continuously monitors the update performance for all of the content updates you run. If updating a specific piece of content takes longer than this amount of time, an optimized update will be performed the next time.
  • Timeouts: If requests to update an entity time out, the next request to update that entity to the same target site will perform an optimized update instead.

Optimized updates are highlighted in the update UI accordingly.

This setting applies for all sites in a space.


Dynamic pool assignments

By default, Content Sync allows editors to remove and change pool assignments. This can result in content deletions when you remove a Pool and the content was previously shared with sites in that Pool. You can disable so that even when a Pool is removed from content, sites that already have the content will keep it forever or until the whole content is deleted on the source site if pushing/pulling deletions is enabled in the corresponding Flow settings.


Private sites

Basic auth protection

If your site requires basic auth protection on top of Drupal, you can enable this.

Before adding basic auth credentials, please change the authentication mode of the module to Cookie in the Settings tab of our module and then re-register the site in the Registration tab.

We recommend whitelisting our static public IPs instead of requiring Basic Auth as Cookie authentication has a worse performance and more potential for issues.


Request polling

If you are using a localhost environment that can't be accessed from the public internet, we can't make requests to your site to request or update content. To workaround this, you can enable our "private environment" sub module.

After enabling, please run "drush cspep" in the background whenever you're working with Content Sync on that site- this will poll for requests and run them locally.

This is the setting controlling whether polling should be used for this site or not; this is set automatically when enabling/disabling the sub module.


Request TTL

When enabling request polling, this setting controls how long a site is allowed to poll for queued requests before they are considered to have failed.


Prefer 2xx status codes

Many CDNs will filter out all responses with a 5XX status code and change the response body. Our module provides controlled responses with 5XX status codes that include important information to troubleshoot potential issues; this information is only shared with our service, so it's not an uncontrolled response to public users that a WAF/CDN is meant to filter out. With this option enabled, sites will respond with a 200 status code even on failure and embed the original 5XX response in the response body.

This allows our service to receive important troubleshooting information in case of failures, so we recommend turning this on if your CDN/WAF filters out 5XX status codes and you're having difficulties troubleshooting potential issues.

This setting applies for all sites in a space.