An installation where content item staging is enabled has a few additional requirements:

  • Presentation hosts must use a separate solr engine 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 solr engine must be set up to use the index web service in order to generate an internal index for use by CUE, while the other must be set up to use presentation-index and 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 TransactionFilter interface has a new method called doStagedUpdate(). The abstract class has 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 TransactionFilterService then failure to add a doStagedUpdate() implementation will result in many NoSuchMethod exceptions. 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.