This page contains details about known design limitations on Content Staging, these will not be fixed in the current implementation of this feature.

Editing content on target servers

Please be aware that editing content on the target server can generate issues regarding content synchronization.
The concept behind Content Staging is to have a staging environment and one or more target environments, allowing editors to manage the content in one single place, and synchronize all to the target server(s) without effort.
However, the content management should only be done in the staging server. Doing that on one of the target servers can make the content to differ among servers (staging and targets), which is already identified as a cause of synchronization failure.

For instance, deleting a content object in one of the target servers won't mean that the content object has been permanently deleted. This is because it has been deleted from a target server only. If an editor updates the same content object existing in the staging server this modification will be sent to the target servers, and when Content Staging tries to update the object on the server from where it has been removed it will encounter an exception, returning that the object being updated doesn't exist. According to this a create action will be sent instead to that target server, and the content object will be automatically re-created.

So, we always advise users to manage the content in the staging server only.

Content Staging on eZ Publish with URL access method

As eZ Content Staging uses REST api, and due to a known limitation, you will require additional configuration in order to make Content Staging work properly.

To do so, please make sure to add your admin siteaccess to the APIPrefix setting, in an override of the rest.ini settings file, as follows:

[System]
ApiPrefix=/<admin_siteaccess>/api

Note: This configuration is only required on the target eZ Publish installations.

In some cases it's also required to apply the patch from jira EZP-21304 in the target eZ Publish installations as well.

If you installed eZ Publish with "Port" or "Hostname" access method you will not be affected by this issue.

Database identifiers like object_id and node_id will differ

Content staging makes heavy use of remote id's and does not sync the internal id's of the objects, this is a feature as it allows for partial sub tree syncs / staging.

For further information take a look in the FAQ for how this affects your use of custom datatypes, custom tags and override rules.