Multiple Content Repositories [v9]

In Neos 9, the system supports multiple content repositories in a single Neos instance. This is useful e.g. in the following scenarios:

• to separate content with data which is imported from external systems (e.g. products)
• to use different dimension configuration for different sites
• to have a different publishing lifecycle for certain elements like products
• to use the content repository as the basis for other PHP APIs, f.e. for asset storage.

There is one limitation right now: The Neos-editable content of a single site must reside in the same content repository right now. This is not a limitation of the Content Repository, but of the User Interface (which cannot track multiple CRs yet).

As a consequence, many classes which were singletons before the rewrite (like the NodeTypeManager) are not anymore, and need to be accessed through the ContentRepositoryRegistry.

The ContentRepository object is the main public API you'll interact with, which you'll retrieve by calling ContentRepositoryRegistry::get($contentRepositoryId). It is responsible for:

• setting up the necessary database tables and contents via ContentRepository::setUp()
• sending commands to the system to mutate state via ContentRepository::handle(Command)
  • catching up projections using ContentRepository::catchUpProjection() (you don't need to call this yourself normally)
• accessing projection state (to read the current model) via ContentRepository::projectionState(ProjectionClass) 
  ... and their specialized accessors (because they are used so much):
  • ContentRepository::getContentGraph() 
  • ContentRepository::getWorkspaceFinder()
  • ContentRepository::getContentStreamFinder() 
• accessing configuration:
  • accessing the NodeTypeManager via ContentRepository::getNodeTypeManager()
  • accessing Dimension Configuration via ContentRepository::getVariationGraph() and ContentRepository::getContentDimensionSource()

The Content Repository named default is automatically registered by the ContentRepositoryRegistry, and is used as the default repository. This is purely a convention though and not hardcoded at any place.

You can register a new ContentRepository by defining it in Settings.yaml. Then, you need to run ./flow cr:setup  --content-repository-identifier <name> to create the necessary database tables.

Each content repository is identified by the key underneath contentRepositories (so custom in the example above).

For each content repository, you can specify the following options:

• preset (required): Which content repository preset to use. This configures the detailed implementation classes of the content repository (read below for details).
• contentDimensions: The Content Dimension Configuration for this content repository (see below for the exact schema).

You'll still need to initialize the new content repository before you can use it, by creating a root content stream and a root workspace. This is done only through PHP code right now as follows:

(TODO: Insert example here)

Configuring Content Dimensions is done through Settings.yaml underneath the Neos.ContentRepositoryRegistry.contentRepositories.<name>.contentDimensions key.

Example:

The above configuration defines two content dimensions language and market. The order of the dimensions is relevant for defining the shine-through (see below). For each dimension, the following properties can be set:

• label: human readable name as shown in the UI. Supports translation, so you can reference a label like Neos.Demo:Main:contentDimensions.language
• icon (optional): visual indicator icon for the dimension selector in the Neos UI
• values: the different top-level dimension values. For each dimension value, you can configure:
  • label: human readable name as shown in the UI. Supports translation. 
  • specializations: dimension values below this value fall back to the parent dimension.
  • constraints: TODO how does this work? :)

The example above configures the following dimension trees:

TODO explain intuition behind

TODO @Bernhard

Currently, the NodeTypes are stored (as always) in NodeTypes.yaml files.

If you want to create contentRepository-specific NodeTypes, you right now need to create a custom preset (see below) and need to override nodeTypeManager.factoryObjectName in the preset.

This is an advanced topic, needed if you want to change how the internals of the content repository work; or if you want to extend it through new projections.

We'll cover the use cases in a deep dive about extensibility later, but we'll here add the reference of the configurable properties underneath Neos.ContentRepositoryRegistry.presets.<presetName>:

• eventStore: how the events are stored and retrieved in the system.
  • factoryObjectName: class name of the factory responsible for building the Event Store. Must conform to Neos\ContentRepositoryRegistry\Factory\EventStore\EventStoreFactoryInterface.
• nodeTypeManager: which node types exist for the content repository
  • factoryObjectName: class name of the factory responsible for building the NodeTypeManager. Must conform to Neos\ContentRepositoryRegistry\Factory\NodeTypeManager\NodeTypeManagerFactoryInterface.
  • options
    • fallbackNodeTypeName (only for DefaultNodeTypeManagerFactory): Node name to return when a NodeType is unknown (to not break editing)
• contentDimensionSource: what content dimensions exist for the content repository
  • factoryObjectName: class name of the factory responsible for building the ContentDimensionSource. Must conform to Neos\ContentRepositoryRegistry\Factory\ContentDimensionSource\ContentDimensionSourceFactoryInterface.
• projectionCatchUpTrigger: after an event is processed in the system, how does the projection catch up run?
  • factoryObjectName: class name of the factory responsible for building the ProjectionCatchUpTrigger. Must conform to Neos\ContentRepositoryRegistry\Factory\ProjectionCatchUpTrigger\ProjectionCatchUpTriggerFactoryInterface.
• userIdProvider: to determine which user ID has executed a command
  • factoryObjectName: class name of the factory responsible for building the UserIdProvider. Must conform to Neos\ContentRepositoryRegistry\Factory\UserIdProvider\UserIdProviderFactoryInterface.
• propertyConverters: Serialization/Deserialization of properties as stored in the CR
  • [name of converter]
    • className: a class implementing Symfony\Component\Serializer\Normalizer\NormalizerInterface and Symfony\Component\Serializer\Normalizer\DenormalizerInterface
• projections: Which projections exist in the content repository
  • [name of projection]
    • factoryObjectName: class name of the factory responsible for building the Projection. Must conform to Neos\ContentRepository\Core\Projection\ProjectionFactoryInterface.
    • options: extra options for the projection factory (currently empty)
    • catchUpHooks: Some projections (like the GraphProjection) allow to hook custom logic into the catch-up process, f.e. to clear caches. This is registered here.
      • [name of catch up hook]
        • factoryObjectName: class name of the factory responsible for building the CatchUpHook. Must conform to Neos\ContentRepository\Core\Projection\CatchUpHookFactoryInterface.