eZ Content Staging

Content Staging is an eZ Publish feature that synchronizes publication contents between two (or more) different eZ Publish installations. 

It aims to synchronizing content with a 100% accuracy, including e.g. objects states, sections, multiple locations etc. Whenever a content is edited on the source server, the changes are recorded locally in the database (not sent immediately). Editors and Administrators can decide which contents to synchronize, via either a dashboard panel or a dedicated page in the administration interface.

Content Staging needs to be installed on both, source and target servers. This means that SQL queries with DB schema must be executed on staging and target servers.

Architecture Type (example):

Example of Content Staging Architecture Type

In this example there is a source server (Server eZsource 1), and target servers (Server eZtarget 1, Server eZtarget 2 and Server eZtarget 3). The synchronization is performed through the REST Service. There is one repository for each environment.

Note: This is only an example. The architecture is flexible and users can configure multiple source and target servers, and create connections between target servers, for instance. Although not usual, it can be done, due to the flexibility of Content Staging.

Triggers and Workflows

The staging set up process involves creating/configuring triggers and workflows.

Workflows and triggers are configured on eZ Publish Administration Interface:

Workflow Groups

You can edit Content Staging workflow groups on this screen.

When you click on "Staging", you can see the workflows available in this group:

Staging Workflows

You can edit Content Staging workflows on this screen.

Note: The workflows must be configured manually in the Admin Interface. To see how to configure workflows, click here.

Synchronization

As editors edit publication contents, events are queued on separate feeds (event logs) and can be synchronized (by a Content Manager, or an Administrator, for instance) between servers/environments.

About Feeds:

• The synchronization feeds are defined on the source server;
• Every feed is used to relay content to one target server;
• For every feed, a set of "root nodes" has to be defined;
• Every content that is a child of one of the feed root nodes will be synchronized to the target server;
• The same content can be part of many feeds that synchronize to different target servers.

Content Staging Back Office Administration Interface:

Synchronization Feeds

There are two events on "ContentTree" feed to synchronize:

Feeds Events

Actions:

• You can synchronize only one event, several events, or all events at a time. Only content events can be synchronized;

• You can delete event logs from the events list.

When deleting event logs, note:

• Create and delete content before synchronization: If you create a folder and delete it, it must be manually deleted from events list before synchronization ("object published" and "object removed" event must be deleted manually from the events list);
• Create and synchronize, then edit, delete and synchronize: The edit ("object publish") event must be deleted manually;
• Create and synchronize, then edit, delete and synchronize: If you delete an object which has children, all events concerning those children will must be also deleted manually.