!!! FEATURE: Add Neos.Neos:Site (singular) NodeType for site nodes

[mhsdesign]

upgrade instructions -> neos/rector#66

@nezaniel suggested in slack

What do you think of introducing the Document type "Neos.Neos:Site" (singular) for site nodes? Should make stuff a lot easier (think of "find current site node" or "decide whether this should have an uriPathSegment"). It's breaky because Projects already on 9.0 need to adjust their NodeTypes config, but it's just one line per site type.

(this got actually 7 thumbs up :D)

and @kitsunet answered with

makes sense to me, maybe even :SiteRoot to make it even clearer it's that single root per site?

---

Our current way of fetching the sideNode is really not ideal or fast:

neos-development-collection/Neos.Neos/Classes/Domain/Service/SiteNodeUtility.php

Lines 40 to 57 in d9c374a

	public function findSiteNode(Node $node): Node
	{
	$previousNode = null;
	$subgraph = $this->contentRepositoryRegistry->subgraphForNode($node);
	do {
	if ($node->nodeType->isOfType('Neos.Neos:Sites')) {
	// the Site node is the one one level underneath the "Sites" node.
	if (is_null($previousNode)) {
	break;
	}
	return $previousNode;
	}
	$previousNode = $node;
	} while ($node = $subgraph->findParentNode($node->nodeAggregateId));
	// no Site node found at rootline
	throw new \RuntimeException('No site node found!');
	}

@nezaniel then i guess it would make sense to leverage #4519 findClosestNode to write:

$siteNode =  $subgraph->findClosestNode($node->nodeAggregateId, FindClosestNodeFilter::create(nodeTypeConstraints: 'Neos.Neos:Site');

[mhsdesign]

The site:create must then expect the Neos.Neos:Site type as homepage node

Or better the Neos.Neos:Sites should declare the constraint to only Neos.Neos:Site

And the Neos.Neos:Document must declare a constraint to not allow Neos.Neos:Site -> never!

[mhsdesign]

\Neos\Neos\Domain\Service\NodeSiteResolvingService::findSiteNodeForNodeAddress and \Neos\Neos\Domain\Service\SiteNodeUtility::findSiteNode

should be refactored to use

$siteNode = $subgraph->findClosestNode($node->nodeAggregateId, FindClosestNodeFilter::create(nodeTypeConstraints: 'Neos.Neos:Site');

[ahaeslich]

@mhsdesign you already mentoined

The site:create must then expect the Neos.Neos:Site type as homepage node

And don't we also have to adjust the legacy data migration? Do we expect users to migrate the old data and change the root node type configuration afterwards? Or do we inform them about the needed adjustments?

[mhsdesign]

Yes i was thinking about this too. Now the legacy migration service asserts that the site node must be of type Neos.Neos:Site.

[mhsdesign]

Existing projects might crash while rendering the site (as we expect the siteNode to be of type Site)

but structure adjustments should find the issue:

./flow structureadjustments:detect

The parent node type "Neos.Neos:Sites" is not allowing children of type "Neos.Demo:Document.Homepage",
                        and the grandparent node type "" is not allowing grandchildren of type "Neos.Demo:Document.Homepage".
                        Thus, the node is invalid at this location and should be removed.

this is ofcourse not ideal and we just need to inform everyone to add this new super type to the homepage - i do hope they have a separate nodeType for that already 🤞

[dlubitz]

i do hope they have a separate nodeType for that already

Most on my projects don't have that 🤷‍♂️

[mhsdesign]

Most on my projects don't have that 🤷‍♂️

okay i see this is definitely a case we need to take care of. Lets move the migration discussion over here:

neos/rector#66