Neos 9.0 and multi-site setups

Using Neos & Flow
1

Hi everyone

I know there are quite some topics regarding Neos and multi-site, but since Neos 9.0 is a game changer rearding separate CRs per site, I could like to revisit the topic - with the goal of having an improved multi-language guide in the Neos docs. So I would like to use this post to collect information about the various aspects of multi-site installations and then use this information for a guide.

Neos 9.0

As presented at Neos Con, Neos 9 will can have one CR per site, so we can have different dimensions per site, which is often needed in multi-site installations.

Sites in Backend

Using the EntityPrivilege for the Site and the NodeTreePrivilege, different Sites can be restricted to different Roles. I assume this implementation won’t change?

I’m not sure about the multi-site compatibility of Sandstorm.NeosAcl yet, does anyone use it in a multi-site context?

Node Types

In contrast to Fusion, Node Types are globally configured, i.e. theoretically every Node Type is available in every site. However, this can be tackled with Node Type Constraints, which I assume will still be the way to go in Neos 9?

Fusion

As mentioned before, Neos loads Fusion code of the current site package, so shared Fusion code can be in an “abstract” package and specific Fusion code in the site package.

Media Management

The current best practise is to use an Asset Collection for each site and use ReadAssetCollectionPrivilege and ReadAssetPrivilege to restrict them to Roles. However, the approach has some drawbacks:

  • A person with access to more than one Site can add an Asset to more than one Asset Collection, making it inaccessible to a user with access to only one site.
  • Editors lose the ability to organize assets in Asset Collections.

As far as I know, both issues should be covered with FEATURE: Hierarchical asset collections by Sebobo · Pull Request #184 · Flowpack/media-ui · GitHub.

  • Asset Collections become hierarchical.
  • It will be possible to limit the UI so an Asset can only be added to one Asset Collection.

Link Editor

I’m not sure yet if the improved link editor must undergo any changes in order to be compatible with Neos 9. I’m also not sure how linking between sites can be achieved and access controlled (I assume you can only create internal links to sites you have read-access to?).

Please feel free to add other topics that are relevant to multi-site installations - and correct my assumptions if I’m wrong. After some time, I’ll try to compile a guide.

1 Like
2

I didn’t use the NeosAcl package yet, but from the screenshot it looks like it can handle only one NodeTree…

Maybe we can extend it to be able to make also Site permissions using the EntityPrivilege and Asset permissions configurable in the backend. I was never happy having to configure all the privileges and roles in the Policy.yamlm this is good for special cases, but for a regular content page I think this should be configurable in the backend.

And if we are talking about Roles, it might also be an option to be able to define privileges on NodeTypes for the Role instead of the Site. This would be close to the way TYPO3 handles permissions, not sure if this is good or bad. :smile:

3

Maybe we can extend it to be able to make also Site permissions using the EntityPrivilege and Asset permissions configurable in the backend. I was never happy having to configure all the privileges and roles in the Policy.yamlm this is good for special cases, but for a regular content page I think this should be configurable in the backend.

I’m not sure if I agree here. IMO, the separation of configuration and content is one of the strenghts of Neos. That way, you can deploy configuration just the way you can deploy code and have one source of truth (your Git repo). So I’m not sure if I really like NeosAcl - apart from it providing a nice UI. If you e.g. want to deploy new user groups or settings to multiple environments of a TYPO3 site (Staging, Production etc.), you need to develop your own tools for it. Or you need to do manual stuff during releases which I think is quite cumbersome. But in this aspect, there may be the clash between requirements for smaller Neos sites without deployment pipelines etc. vs. larger sites.

4

We still have to implement a privilege for the nested collections that will not destroy performance. Discussed it last week or so again with @bwaidelich and we think separate Neos asset sources for sites or complex restrictions would be much easier. But we have to look into the implementation details.

5

You are right about the deployment of multiple environments, I didn’t think about that.

But at the same time, as a developer I don’t want to write policies for every case of User A having access to this node tree and those assets and User B having that too but also access to another site… especially for larger projects there is often one “power user” that would handle the permissions for all the backend editors.

But may be I just have to craft the roles better…

6

Hey, Great topic and initiative :slight_smile:

I am currently on my mobile phone, so bear with me that my thoughts are quite short :wink:

It can have different CRs, but does not need to.

The permission system of Neos 9 will change; and this is not yet done. This is our biggest todo until the release this fall :slight_smile:

In Neos 9, we already have a different node type manager per CR instance; right now they all load the same node types from the NodeTypes folder though. So it is all prepared for different node types per CR once we agree how to configure it :slight_smile:

This is not implemented yet; but our idea was to make the node:// links extensible - so we could either use node://cr-Id/node-id or a new „protocol“

If you like to work on any of the things above (or need it for a project), let me know :slight_smile:

All the best,
Sebastian

1 Like
7

Just a couple of additions and links to related issues:

The new NodeTypeManager is really basic so far. I’ve collected some ideas with @Nezaniel at the NeosCon and he wanted to start working on that, see: Overhaul 9.0 `NodeTypeManager` · Issue #4228 · neos/neos-development-collection · GitHub

Entity Privileges need an overhaul, as @sebastian wrote. They became overcomplex and aren’t easy to use at all. Here is an issue with some ideas and a first PoC: 9.0: Re-Implement Policies / Security for CR · Issue #3732 · neos/neos-development-collection · GitHub

As for assets I hope that we can extend the notion of Asset Sources so that it is easily possible to configure two different Neos asset sources in one installation for example. And then, instead of linking an AssetCollection to a site, a site could be linked to one or more Asset Sources instead