Content staging

Staging allows you to easily transfer changes made to pages or objects from one Xperience instance to another Xperience instance (typically hosted on a different server). You can also perform complete synchronization of all pages and objects. All connected instances must use the same version of Xperience. Staging is particularly useful if you need to synchronize multiple environments during development, for example:

Development -> Testing -> Editing (staging) -> Live (production)

All pages stored in the content tree of websites can be synchronized. However, not all objects in Xperience support synchronization. Make sure you read through the What can be synchronized section for more information.

Staging topology overview

Every “instance” within the staging topology consists of the following components:

• The Xperience administration application used to manage content and objects
• The MVC application that provides the live website
• One Xperience database shared by the applications

Configure staging between the Xperience administration applications, which then provide the transfer of data between the databases of the given instances. The MVC applications within individual staging instances then use the shared data to present the website.

What can be synchronized

Content staging supports synchronization of the following data:

• Page data – pages in the website content tree, their content, URLs, and more.
  • Pages need to be on the same place in the content tree on both the source and target servers.
  • Timeout defined for pages that are part of a workflow is not synchronized for consistency reasons.
• Page file attachments – if a page contains attachments or file fields, the files are synchronized together with the page.
• Page relationships – relationships between pages are synchronized if the relationship type and both pages exist on the target server.
• Page templates created for MVC pages – synchronization is supported only for custom page templates (which are created from a default page template).
• Personas
• Workflow process – only published page versions are synchronized to the target server and both servers need to have the same workflow schema defined.
• Email feeds – when staging email feeds, we recommend setting the staging of child and binding objects to incremental to avoid overwriting individual email issues and their statistics.
• Email widgets
• Custom tables and their data.
• Media libraries and the files and folders in them.
• ACLs (page-level permissions)
• Global objects – all global objects with the exceptions listed below.

Content staging does not supportsynchronization of the following data:

• Accounts
• Activities
• Contacts (the state of contacts in automation processes is also not synchronized)
• Custom modules
• Event log
• Export history
• Form data (the actual form objects are synchronized)
• Sites (the global objects holding the properties of sites in the system)
• Web farm servers
• Object data fields that store various types of live site data or statistics (e.g. the status and statistics of campaigns)
• Physical files associated with global objects (for example web part source file, form control files)
• Database views and stored procedures managed through the Database objects application
• Object code stored and edited in physical files via deployment mode or source control mode
  • On source servers, staging tasks are generated only if you edit code in the Xperience administration interface or after you synchronize changes from files into the database.
  • On target servers, staging tasks do not update object code if deployment or source control mode is enabled.