-
-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"internal" node properties in Fusion/UI #4208
Comments
This is related to #3434 as that is using them. However I have a fix prepared for that. |
in 7.3 for example these are the node properties which can be accessed via the internal property syntax: properties which are declared in the original NodeInterface:
for completion (unrelated but i just wanted to document it) these are the settable properties a la NodeInterface:
additionally accessible properties because of the TraversableNodeInterface and Node.
but since we kept the dynamic internal access in 9.0 if ($propertyName[0] === '_') {
return ObjectAccess::getPropertyPath($element, substr($propertyName, 1));
} we will also allow in the future some magic wizardry for these (new) 9.0 properties:
im against that. Keeping a legacy layer: Ok but i would refrain from allowing new magic accessors. also there are futher cases like here: Line 123 in 7ac9942
|
Suggestion mentioned in daily today is to actually fully abandon these as it will just lead to confusion with people when some still work. Lets rather migrate them and offer alternatives where it makes sense. |
100% agree. Additionally we should discuss if |
Please check also the already created rector migrations: |
To avoid confusion, and since we have rector migrations in place, we decided in the weekly that we wanted to drop the legacy layer: https://github.com/neos/neos-development-collection/blob/8d7acb506d87c76b47bf9114dddd696bee15fdab/Neos.ContentRepository.NodeAccess/Classes/FlowQueryOperations/PropertyOperation.php#L93C1-L100 and not further support the underscore We should especially look at some node types as the underscore |
Unfortunately we actually added |
What about a NodeMigration to rename the property? |
But rename it to what? 😆 The thing is ... complicated, I can explain in the weekly... or write it out here later. |
|
As decided in our weekly today, the plan is to:
|
Provides a helper to access hidden status as well as renaming `_hiddenInIndex` to `hiddenInMenu`. Fixes: neos#4208
Todo: explicit eel ordering support via time stamp fields: https://neos-project.slack.com/archives/C050C8FEK/p1709887830143079?thread_ts=1709403062.357079&cid=C050C8FEK currently in 9.0-dev its |
…nd filter FlowQuery Fixes neos#4208 (comment)
Not yet -> #5015 |
Update 2024 these are all the properties accessible in the Neos 8 Node (via
new additional properties in 9.0
Invalid gettable properties as they require arguments:
legend
|
Currently there is this in Neos.Neos/NodeTypes/Mixin/Node.yaml
And yes unsurprisingly this is breaking in multiple ways. These are assumed ot be there at least in the NodeInfoView but probably in other places, also userland code might use those ala
q(node).property('_path')
which is perfectly "legal" at the moment. So we need to adapt internal usage and create migrations for userland code if we want to get rid of those (as well as create an accessor for them I guess?)The text was updated successfully, but these errors were encountered: