Releases · Flowpack/Flowpack.NodeTemplates

23 Dec 08:52

mhsdesign

2.1.1

a1bbc58

2.1.1 Latest

Latest

What's Changed

TASK: Introduce phpstan level 5 by @mhsdesign in #75
TASK: Add information about showInCreationDialog and custom EEL helpers to readme by @lorenzulrich in #76
TASK: Allow NeosUi 8.4 by @mhsdesign and @ahaeslich in #78

New Contributors

@lorenzulrich made their first contribution in #76

Full Changelog: 2.1.0...2.1.1

Contributors

ahaeslich, lorenzulrich, and mhsdesign

Assets 2

02 Aug 12:31

mhsdesign

2.1.0

5f7ff7f

2.1.0

Node Templates Version 2.1

As version 2.0 https://github.com/Flowpack/Flowpack.NodeTemplates/releases/tag/2.0.0 might have been breaking for your project, and it was tedious to validate that youre templates still work, you can now utilize the new feature to validate simple node templates!

Validate simple node templates

It might be tedious to validate that all your templates are working especially in a larger project. To validate the ones that are not dependent on data from the node creation dialog (less complex templates) you can utilize this command:

flow nodetemplate:validate

In case everything is okay it will succeed with X NodeType templates validated..

But in case you either have a syntax error in your template or the template does not match the node structure (illegal properties) you will be warned:

76 of 78 NodeType template validated. 2 could not be build standalone.

My.NodeType:Bing
 Property "someLegacyProperty" in NodeType "My.NodeType:Bing" | PropertyIgnoredException(Because property is not declared in NodeType. Got value `"bg-gray-100"`., 1685869035209)

My.NodeType:Bar (depends on "data" context)
  Configuration ""${data.aListOfThings}"" in "childNodes.pages.withItems" | RuntimeException(Type NULL is not iterable., 1685802354186)

The standalone validation should detect errors and prevents editors having to deal with these errors at runtime.

For more complex templates, which are dependent on the node creation data, it is recommended to write separate tests. Currently, errors in templates depending on the data context will only be treated as warning, as they are probably not an issue at runtime.

What's Changed

TASK: Cleanup test by @mhsdesign in #65
TASK: fix tests on Neos8.3 by @mhsdesign in #68
BUGFIX: correct node constraint checks by @mhsdesign in #67
FEATURE: flow nodeTemplate:validate validate templates standalone by @mhsdesign in #58
BUGFIX: Position TemplateNodeCreationHandler to the end by @mhsdesign in #46
BUGFIX: Skip unset configured childNodes by @mhsdesign in #73
TASK: code review by @mhsdesign in #74

Full Changelog: 2.0.1...2.1.0

Contributors

mhsdesign

Assets 2

19 Jun 11:27

mhsdesign

2.0.1

970643b

2.0.1

What's Changed

BUGFIX: TransliterateNodeName to allow setting properties on a childNode with invalid name by @mhsdesign in #56
TASK: NodeCreation: Check if node is abstract or if node is not allowed explicitly by @mhsdesign in #57
BUGFIX: NodeType is not initialized in super rare edge cases by @mhsdesign in #59
TASK: Run automated Tests via CI by @mhsdesign in #63
BUGFIX: Use property mapping for type: SomeClass or array<SomeClass> by @mhsdesign in #62

Full Changelog: 2.0.0...2.0.1

Contributors

mhsdesign

Assets 2

07 Jun 15:30

mhsdesign

2.0.0

a3684ba

2.0.0

Node Templates Version 2.0

With this new major release, we strive to make the version 2.0 template syntax and behaviour as close to the upcoming version 3 for Neos 9.
So you can for example expect stricter validation for properties already right now.
This mentality will make it easier to have a more similar code-base and also be able to easily backport features to the Version 2.
For that reason the whole code-base was refactored. With the most prominent changes being a two-step procedure to process the template and then start the node creation. Also a graceful exception handing wraps now nearly every operation.
This release is breaking for lots of edge cases but the error logs will hopefully be a helping compensation :D

!!! Refactoring: Two-step procedure to process the template and then start the node creation

Previously the template configuration was processed and nodes were created in the same step - coupled together. This was suboptimal architecture for the reasons:

It didn't allow us to properly test the template configuration processing separately
We couldn't prevent the template from being applied if somewhere an exception was thrown. See issue
The implementation of the content repository handler could not be switched out easily say for Neos 9

FEATURE: Graceful exception handing. Log errors and continue with the next operation.

In the first step the configuration is processed, exceptions like those caused by an EEL Expression are caught, and any malformed parts of the template are ignored (with their errors being logged).
This might lead to a partially processed template with some properties or childNodes missing.

You can decide via the exception handling configuration Flowpack.NodeTemplates.exceptionHandling, if you want to start the node creation of this partially processed template (stopOnException: false) or abort the process (stopOnException: true), which will only lead to creating the root node, ignoring the whole template.

Flowpack:
  NodeTemplates:
    exceptionHandling:
     templateConfigurationProcessing:
        stopOnException: false

In case exceptions are thrown in the node creation of the template, because a node constraint was not met or the type field was not set, the creation of the childNode is aborted, but we continue with the node creation of the other left over parts of the template.
It behaves similar with properties: In case a property value doesn't match its declared type the exception is logged, but we will try to continue with the next property.

Changes in sight of Neos 9 ESCR forward compatibility

!!! The functionality to set internal node properties via _foo property syntax, which was introduced with was reverted.
This was done in preparation for the Neos 9 ESCR to be forwards compatible. A new properties._hidden: true equivalent is in the work already see pr. In case you need support for another node option that will still be available in the new ESCR, please create an issue and let us know. In the other case you can stay on the previous v1.x Version of this package.
!!! Like in Neos 9 we will validate that the property type declaration of the NodeType matches the given value. In case of a mismatch the property will not be set and an Error message will be displayed.
!!! Also like in Neos 9 properties have now to be declared in the NodeType and will otherwise not be set.
The option nodeCreationDepth was removed. It was previously more of a necessity as it was needed for the property mapper. Now the whole template will be evaluated and applied.
!!! Previously EEL Expression could not only access the triggeringNode but also the current node and parentNode. Due to the two-step approach, first evaluating the template, you will only have access on to the triggeringNode.
In version 3 the nature of the new Neos 9 API won't allow you to access the triggeringNode but presumably only the current subgraph.
!!! Experimental extensibility via Signal and the options array introduced with will also be dropped as the use case was unclear and conflicts with the refactoring to the mentioned two-step approach.

Other changes

Many tests have been written to make sure the package is working as previously and increase its stability
EEL expression are now determined if the string starts with ${ instead of trying to check if there is a valid expression. This will help in cases where the malformed expression was saved as property value instead throwing an error. See issue
Previously variables of withContext where not accessible in the root uriPathSegment.
The strategy for the uriPathSegment generation of child pages was changed from Neos\ContentRepository\Utility::renderValidNodeName($properties['title'] ?? null) to Neos\Neos\Utility\NodeUriPathSegmentGenerator::generateUriPathSegment($node, $properties['title'] ?? null)
The uriPathSegment on the template root node will be either based on the template property properties.uriPathSegment or defaults to the slug generated from the creation dialog's data.title (The original behaviour).
Template Configuration Validation
- Its is now ensured that only ['properties', 'hidden', 'childNodes', 'when', 'withContext'] is set on the root template. The other options were previously silently ignored.
- The option type is not allowed to be set for auto-created child nodes. We don't allow to change the type right now. We never did.
- The option type must be set to a valid existing NodeType for to be created nodes. Previously it would fall back to the configured fallback like: Neos.Neos:FallbackNode.
- !!! Now template configuration properties are stricter validated and can only hold non array types like int|float|string|bool|null. (Using nested arrays might come in handy for new features later like for setting Neos 9 reference properties.) Previously it was also possible to set a property to a list like propertyName = ['foo', 'bar'] instead of using EEL: propertyName = "${['foo', 'bar']}".
Bugfix: Only EEL expression were allowed in root level title and uriPathSegment now simple strings work too
Bugfix: EEL expression was not parsed when uriPathSegment was build from title property in childNodes

See PR: #53

Full Changelog: 1.4.1...2.0.0

Assets 2

05 Jun 15:39

mhsdesign

1.4.1

92d5735

1.4.1

What's Changed

BUGFIX: Name command method correctly by @mhsdesign in #52

Full Changelog: 1.4.0...1.4.1

Contributors

mhsdesign

Assets 2

01 Jun 11:53

Sebobo

1.4.0

9042e5a

1.4.0

What's Changed

BUGFIX: Parse EEL Expressions in "type" by @mhsdesign in #38
BUGFIX: catch and enhance errors caused in EelExpression by @mhsdesign in #39
FEATURE: withContext to define reusable variables and f.x. preprocess nodeCreation dialog items by @mhsdesign in #42
TASK: Known exceptions are logged to the Neos.Ui and caught by @mhsdesign in #44
FEATURE: Create node template definition yaml dump from node subtree by @mhsdesign in #40