An installation where content item staging is enabled has a few additional requirements:
Presentation hosts must use a separate
solrengine from editorial hosts. This is already the recommended configuration for production installations, but if content item staging is enabled then it is an absolute requirement. The Content Store provides two indexer web services for logging updates to content items: one of them (
index) logs all changes and the other (
presentation-index) excludes changes made to staged content items. One
solrengine must be set up to use the
indexweb service in order to generate an internal index for use by CUE, while the other must be set up to use
presentation-indexand generate an index for use by the presentation layer. For further information, see Search Engine Configuration and Management.
If your application includes any event listeners, you will probably need to extend them to accept events for staged content items. A new marker interface,
neo.xredsys.api.StagedEventListener, has been added for this purpose. For detailed instructions, see Handling Staged Content Item Events.
If your application includes any transaction filters then you will probably need to modify them. The
TransactionFilterinterface has a new method called
doStagedUpdate(). The abstract class
neo.xredsys.api.services.TransactionFilterServicehas also been updated with a "do nothing" implementation of this method. This means that if your transaction filter is based on
TransactionFilterService, it will ignore updates to staged content items unless you add an implementation of
doStagedUpdate()to it. If your transaction filter is not based on
TransactionFilterServicethen failure to add a
doStagedUpdate()implementation will result in many
NoSuchMethodexceptions. For further information see Transaction Filters.
If your application includes any post-transaction filters, then they will probably need the same kinds of modifications as transaction filters.