FEATURE: Neos 9.0 compatibility

[mhsdesign]

This change introduces support for Neos 9.

When starting the development it was eminent that not all features of NodeTemplates version 1.0 could be considered. To ease maintenance the version 2 of NodeTemplates was a complete rewrite for this package in anticipation of Neos 9. It removed incompatible features but also introduced new functionalities. The core functionality was rewritten to not depend on active records so it can be adjusted to issue a set of content repository commands. That way it became possible to reuse the test-suite as well as parts of the core domain and be up-mergeable. Multiple up-merges from version 2 have been successful and this strategy will allow us to fix bugs or ease introducing new minor features.

That being said all features of NodeTemplates version 2 are herby adjusted/refactored to work with Neos 9 while passing all tests:

Core functionality, NodeTemplates via options.template

Full support of the feature set of version 2. The deprecated EEL context variable triggeringNode was removed as discussed. Please use site or parentNode instead.

flow nodetemplate:validate

Includes new --site option: the Neos site, which determines the content repository. Defaults to the first available one.

flow nodeTemplate:createFromNodeSubtree

Includes new --site option: the Neos site, which determines the content repository. Defaults to the first available one.

Additional notes

• introduce PHPStan Level 8
• run ci for PHP8.2 & PHP8.3
• align uri path segment generation to 9.0 NodeCreationService::generateUriPathSegment (see also discussion to move it into the core)
• The custom build declarative way to change the cr in version 2 via Flowpack\NodeTemplates\Domain\NodeCreation\NodeMutator was replaced by using native ESCR commands
• adjust fully to NodeType properties/references split, which is already partly part of the version 2 philosophy
• use public constructor promotion for TransientNode but not in other parts that should be up-mergeable (like Template)
• discuss how to calculate node aggregate ids of tethered nodes. We decided against making them deterministic here.
• Builds on the Neos.Ui node creation handler refactoring https://github.com/neos/neos-ui/pull/3519
• Requires this Neos 9 bugfix: https://github.com/neos/neos-development-collection/issues/4351
• Implements workaround for this Neos 9 "bug": https://github.com/neos/neos-development-collection/issues/5154 / see also https://github.com/Flowpack/Flowpack.NodeTemplates/issues/41

[mhsdesign]

Some notes:

related: https://github.com/Flowpack/Flowpack.NodeTemplates/issues/50

related: https://github.com/Flowpack/Flowpack.NodeTemplates/issues/35#issuecomment-1550819560

references need special handling: https://github.com/neos/neos-ui/blob/4681fd003d9f9b6a14a47440d859265bad35044e/Classes/Domain/Model/Changes/Property.php#L152-L180

---

Question is, how to support usecases like #60

            childNodesToCopy: "${q(node).find('#' + data.templateNodeIdentifier).children('main').children().get()}"

as flowquery will only work with a "real" node and we have one yet. Maybe we need a helper for this?

Neos.Node.findNodeById(id, subgraph)

edit: as discussed in https://github.com/Flowpack/Flowpack.NodeTemplates/pull/70#discussion_r1255520140 we will make the parentNode or site node available ;)

[theilm]

Question is, how to support usecases like #60

I think for this use case, the flowquery is not the problem: the nodes we try to get should be already materialized. The problem is: ATM we can copy the nodes when reacting to the signal; in the future, the target is not yet materialized and we have to modify the template based on the nodes we want to copy. Although this would be part of the package implementing the feature, we should think about how this could be done.

[mhsdesign]

The node creation handler overhaul was merged https://github.com/neos/neos-ui/pull/3519 and the node was made workspace aware https://github.com/neos/neos-development-collection/pull/5042, the biggest changes in Neos 9 that would affect this package are done and the main functionality of this package is now fully compatible (without patches) with the latest beta Neos9-Beta10. That means we can merge this into a target branch wed like to eventually tag a first V3.0 some time. ~We can merge into master (though its behind 2.0) or create a new main branch, or create just a 3.0 branch. Your choice :D~ Edit lets do 3.0