Limitations to promoting data

SiteSync module intentionally imposes several limitations to the content promotion process. These limitations are implemented by design and cover the following:

Bi-directional sync (A<->B)

SiteSync can be configured to promote content only in one direction. You cannot use SiteSync in scenarios where you need to keep two environments in bi-directional sync (content editing happening on both environments and using SiteSync to push content to each other). This scenario is not supported as it might result in overwriting content and data loss.

Promoting content to one destination from multiple sources (A»B, Z»B)

SiteSync does not support promoting content to one target environmen»t from multiple source environments. By design the module handles content promotion from one source environment to one or more target environments. Promoting content from multiple sources to one destination may result in unexpected behavior, database conflicts, or potential data loss.

Only content changes visible on the website frontend mark an item as pending for sync

SiteSync only detects content changes that affect the content visibility on the website frontend, that is, Publish or Schedule operations. In other words, once you publish an item or schedule it for publishing / unpublish, SiteSync marks this item as pending sync. Any consecutive changes you apply to the item from the moment of publishing / scheduling until you perform the sync operation will also be included. After promoting an item, it is no longer marked for sync, until you apply a schedule or publish operation to it again. For example, if you promoted the published item, and then unpublish it, SiteSync will not consider this item as pending sync. If you unpublish the same item, then publish again, and finally unpublish (or save a new draft), SiteSync will mark the item as pending sync with its latest status – Unpublished (or Draft, newer than Published) and you will be able to promote these changes. The following diagram visualizes this behavior:

 

MarkedForSyncTimeline_clean

SiteSync does not create revision history

When promoting content to the target environment, SiteSync does not update the publication date and does not create a revision history entry for the item. This behavior is by design since SiteSync uses a different mechanism for content manipulation than the standard Sitefinity CMS one. For the sake of optimal performance for content at scale, SiteSync does not include some features of the standard Sitefinity CMS content manipulation mechanisms, such as workflow, lifecycle, and versioning.

All changes must first be applied on the source environment

Once you configure your environments and start promoting content using SiteSync, you must absolutely restrict the following actions on the destination environment(s):

  • Configuration changes
    The configurations of the source and destination environments need to match, so SiteSync can operate normally. Performing any configuration changes (such as adding a new website, language, or modifying a dynamic module) on the destination environment will result in the two environments having different configuration files and consequently different behavior. This will lead to failed content promotion operations, unexpected behavior, and potential data loss. When using SiteSync, any configuration changes must be applied on the source environment first, and then promoted to the destination environment(s) using a mechanism you prefer (for example via deployment in combination with the Sitefinity CMS import/export functionality or by manually copying the configurations and restoring the DB. For more information see Best practices: Difference between SiteSync and Export / Import. Once you have taken care of promoting the configuration changes you can continue using SiteSync as a mechanism to promote content.
  • New content creation or content deletion
    New content must only be created on the source environment and then promoted to the destination environment via SiteSync. Creating content directly on the source environment will result in database differences between the two environments and can lead to unexpected behavior when SiteSync is used (for example, duplicate content IDs, broken parent-child hierarchy, and potential data loss).
  • NOTE: Even in cases where you need to apply an urgent content change, keep in mind SiteSync pushes content to the destination environment in a very efficient manner. Minor content changes get applied almost instantaneously, so you must simply sync on demand the required content. If, however, you absolutely need to create the content on the destination environment first, you must then take care of restoring the modified destination environment database to the source environment. This way you will restore the sync between the two environments, and only then you can continue using SiteSync.

  • Content edits
    Content editing must always be done on the source environment, and the changes must then be promoted to the destination environment(s) via SiteSync. If you edit content directly on the destination environment, you risk losing these changes the next time you promote content from the source environment using SiteSync. SiteSync always overwrites the existing content on destination with the content you are promoting from the source environment. If in case of an emergency you edit a piece of content on the destination environment, you must make sure to apply the same change on the source environment before you use SiteSync.

Was this article helpful?