This document includes a list of frequently asked questions about eZ Content Staging LS 5.3 extension.

Q: Can a feed be defined on a subtree of already existing content?
A: It is recommended to have no content for either source or target feed sources when creating the feed. However, synchronization is possible if both source and target servers share the same data (for example, if target servers use a DB copy of the source). In this case, the feed initialization event may seem to fail, but it should not be needed as the the "remote_id" for the main nodes is already the same. Also, if we apply a copy of the source's database into the targets the feed initialization event won't be necessary. The feed initialization event exists to make sure that the content in source and target servers share the same remote-id, and using a database dump from the source to build the content subtree on target servers will make them to have the same information, including the same remote-id's. So, in this case, the feed initialization event will not be required.

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: Only datatypes with full support for toString() and fromString() are supported. 
This means that among others, eZSurvey isn't supported. Syncing the attribute won't cause any error,but the attribute will be empty.

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. Additional documentation is provided with the sources, in the doc/ folder within the extension, in the specs.ods file.

Q: How does the extension cope with synchronization of "dictionary" data, such as sections, object states, content class definition?
A: So far, this is left to manual synchronization.

Q: Can I continue using node id's and object id's in override settings?
A: Not for new synchronized content as these will get separate id's over time, remote id's and identifier's are however safe to use.

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 but No. This has not been extensively tested or supported, but it should work in theory. The main hurdle is setting up the REST layer to use the current eZ session cookie for authentication purposes;  to this end you should set in rest.ini AuthenticationStyle=ezpRestSessionAuthStyle.
Note: Doing so means that the "anonymous user" can access all methods available via the REST API. Be aware that some methods may not enforce proper policy checking.