se7enxweb/ezcontentstaging

eZ Content Staging provides content synchronization from one eZ Publish installations to another via REST configured on both instalations of eZ Publish. Great for smarter developers!.

1.2.1 2024-01-29 07:28 UTC

Requires

• se7enxweb/ezpublish-legacy-installer: *

GPL-2.0-or-later

• 7x
• eZ Publish dev-team & eZ Community

README

The goal of the extension is to allow content synchronization between different eZ Publish installations.

The general architecture is the following:

Feeds

. on the source server, "synchronization feeds" are defined . 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 editing

. the extension aims to synchronize 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 the website toolbar (frontend), a dashboard panel or a dedicated page in the administration interface

Communication between the servers

. the communication between the source and target servers happens via REST calls (with a small divergence from the standard http protocol in usage of custom verbs) . the extension needs to be installed on both source and target servers

Installation

Read the INSTALL file for both requirements and instructions

FAQ

. q: can a feed be defined on a subtree of already existing content? a: not yet. It is recommended to have no content for either source or target feed sources when creating the feed . q: can content sync happen immediately without intervention of the editor? a: not yet . q: can content sync happen via a cronjob? a: yes . q: are all datatypes supported? a: the extension support all datatypes from eZ Publish, plus datatypes that support fully toString(), fromString() calls and do not rely on object_id/node_id or other database data . q: are custom tags for rich text supported? a: all tags that do not rely on object_id/node_id or other database data should be fine . q: is the REST protocol used for communication between the two servers documented? a: yes. It is in fact a "preview" version of the protocol that will be the official next version of the ezrest api. Documentation is provided: - in the doc/ folder within the extension, in the specs.ods file - automatically-generated via the REST url contentstaging/v1/api/versions . q: how does the extension cope with synchronization of "dictionary" data, such as sections, object states, content class definitin? a: so far, this is left to manual synchronization . q: can I use the REST API in this extension independently of a staging context, and have AJAX clients use it to edit content on a single eZ Publish server? a: yes. This has not been extensively tested, but it should work. The main hurdle is setting up teh REST layer to use the current eZ session cookie for auth purposes; to this end you should set in rest.ini AuthenticationStyle=ezpRestSessionAuthStyle. NB: doing so means that the "anonymous user" can access all methods available via the REST api - take care if there are some such methods that do not enforce proper policy checking . q: what is the difference between the version of this extensions on projects.ez.no (github.com/gggeek/ezcontentstaging) and the official version from eZ Systems (github.com/ezsystems/ezcontentstaging)? a: the "community version" extension was the first to be developed. It it still being maintained, and it strives to be a "beta" version where features are implemented before being imported in the official version. The REST protocol in use is the same, so you should be able to interoperate between the two extensions.