9.1.3 (2026-02-12)
Overview of merged pull requests
BUGFIX: Add Missing ChangePropertyTypeFromScalarToBackedEnum transformation
This was simply missing in the default settings
Upgrade instructions
none
Review instructions
none
Packages:
Media.BrowserNeosWorkspace.Ui
BUGFIX: Comments must not be null when handled to string functions
Resloves: #5697
Packages:
ContentRepository.NodeMigration
BUGFIX: Relax descendant node type checks to allow matching tethered children on node type change
Given I have Node Types A and B that both have the same tethered descendant named whatever of type C that would not be allowed as a child if it was not tethered
When I tried to change Node Type from A to B (e.g. via migration) this would fail because C is not allowed as child of B
I’ve added a check to match the tethering configuration; in this case the node of type C can stay as a tethered child even after the type change from A to B
Upgrade instructions
none
Review instructions
Check the tests or try this at home :)
Packages:
ContentRepository.Core
BUGFIX: Prevent root nodes from being copied when moving the empty DSP
Until now, root nodes were copied when moving from zero to more dimensions, leading to unexpected behavior
Upgrade instructions
If you ran into issues when executing a MoveDimensionSpacePoint migration from the empty DSP, replaying the graph projection is necessary
Review instructions
please check the tests, the implementation is rather trivial
Packages:
ContentGraph.DoctrineDbalAdapterContentRepository.BehavioralTests
BUGFIX: Allow possible translation value to be null
If the value of a potential translateable field is null, the trim function complains about a non-string value. So we check now upfront, if the value is null.
`
trim(): Argument `#1 <https://github.com/neos/neos-development-collection/issues/1>`_($string) must be of type string, null given
`
Packages:
NodeTypes.ColumnLayoutsContentRepositoryRegistry
BUGFIX: Allow possible translation value to be null
backport of https://github.com/neos/neos-development-collection/pull/5722
Upgrade instructions
Packages:
NodeTypes.ColumnLayoutsNeos
TASK: Add tests for content cache flushing on subtree tagging
Adding additional behavioral tests for content cache flushing when adding and removing subtree tags.
Packages:
Neos
TASK: Improve contribution guidelines
These are some slight adjustments to the contribution guidelines, to make them a bit easier to digest. I mainly added the following:
table of contents, to make finding specific content easier
a couple of direct links to various section headlines, where previously we had just a standin “read further down below”
a note block to the branching model, so it gets better visual highlighting
TASK: Improve pr template
While working on my first feature I noticed that the various contribution guidelines sometimes contradict each other or are not perfectly clear.
This PR is part of trying to improve this for the forking/branching-model. However I am not sure if I’ve got the facts right in the first place 😅 - @Sebobo ?
Furthermore I do think it would be useful to consolidate all of that information into one single source of truth instead of having it repeated across multiple pages. Apart from the pr-template these are some of the pages which are being referenced across various docs: - https://discuss.neos.io/t/creating-a-pull-request/506 (referenced by `this discuss post <https://discuss.neos.io/t/code-contribution-guideline/503>``_, which istelf is being referenced by ``the contribution guidelines in this repo <https://github.com/neos/neos-development-collection/blob/9.0/CONTRIBUTING.md>`_ - https://docs.neos.io/guide/contributing-to-neos/neos-core#contribution-workflow
In my opinion it would probably make the most sense, if all necessary information was part of the CONTRIBUTING.md-file. The neos docs site could also be shortened and just point to the markdown file. I would also remove the links to these discuss posts and just make sure that all information is part of the markdown file and up to date.
The CONTRIBUTING.md file is typically the documentation I would be looking for when contributing to open source and standard practice. Though having a couple of lines directly inside the neos docs to point newcomers to this resource would still definitely make sense.
What do you think?
Packages:
.github