Path

ez.no / documentation / ez publish / user manual / 5.x / content staging / known limitations


Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.
For 5.x documentation covering Platform see eZ Documentation Center, for difference between legacy and Platform see 5.x Architecture overview.

Known limitations

This page contains details about known limitations on Content Staging.

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.

Workflows on target servers

According to the way Content Staging has been designed, running workflows in the target servers can generate issues on synchronizing content.

For example, if you use the "Wait until date" workflow in one target server the content will not be published until a certain date comes, and the publish notification will not be properly delivered. So, for the staging server that information has failed to be published, but the workflow will publish it when the defined date comes, on target servers. The staging server will consider that publishing event a failure, but the content has been successfully sent to the target, and the pending publish event will continue to fail every time a synchronization occurs.

To avoid such issues we advice to have workflows on the staging server only. That way we will not have issues, as the workflows run on the staging server, and only after the content is published it will be synchronized to the target servers.

Ricardo Correia (18/06/2013 1:48 pm)

Ricardo Correia (29/07/2013 2:25 pm)


Comments

There are no comments.