-
-
Notifications
You must be signed in to change notification settings - Fork 223
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
!!! TASK: Rename _hiddenInIndex
to hiddenInMenu
#4921
!!! TASK: Rename _hiddenInIndex
to hiddenInMenu
#4921
Conversation
unrelated errors 🤷 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one comment for now. Apart from that, the PR looks great!
You mentioned that there are follow-up todos for Neos UI?
Looking at this PR I noticed
|
The internal property `hiddenInIndex` was renamed to `hiddenInMenu`. To match this renaming the fusion property `renderHiddenInIndex` is renamed to `renderHiddenInMenu`. Needs: neos/neos-development-collection#4921
Rector btw. is here neos/rector#45 |
|
These testfailures seem again unreltaed? |
ok interesting, those tests are from a recently merged PR in 9.0, but why do they show up here given that they are not in my branch? Note this is because we get the "merge" PR branch in tests that is actually a representation of 9.0 HEAD + this PR branch and not just plainly this PR branch. |
FYI: Karsten said just renaming the labels should be fine. |
Neos.Demo: neos/Neos.Demo#192 |
I'd like to help here but can't get PHPStorm to detect the merge conflicts... |
I can try to get it back on track, somehow I thought iut was long merged 🙈 |
neos-ui change: neos/neos-ui#3735 |
what parts are still missing here? All that I can see looks very nice already |
Nothing IMHO, it should all be merged please 😆 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking care.
To solve the issue #4208 fully we have to get rid of ObjectAccess
in the property
operation as well and possibly also in other places.
But instead of adding this into this pr and bloating it up i would like to suggest to keep this pr super simple and only related to _hiddenInIndex
-> hiddenInMenu
that way its much more structured.
All the general underscore _
logic could then be removed in one batch with another pr. What do you say? I might also be able to help with that.
Neos.ContentRepository.NodeAccess/Classes/FlowQueryOperations/FilterOperation.php
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, even with the unrelated changes
Provides a helper to access hidden status as well as renaming `_hiddenInIndex` to `hiddenInMenu`. Fixes: neos#4208
05e6552
to
565bff1
Compare
_hiddenInIndex
to hiddenInMenu
Extracted everything i though this pr was originally meant to be into #5015 and added the things i found missing. This pr now is super slim and only addresses the Followups: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be merged after a nice description has been added ;)
if ($this->renderHiddenInIndex === null) { | ||
$this->renderHiddenInIndex = (bool)$this->fusionValue('renderHiddenInIndex'); | ||
if ($this->renderHiddenInMenu === null) { | ||
$this->renderHiddenInMenu = (bool)($this->fusionValue('renderHiddenInMenu') ?? $this->fusionValue('renderHiddenInIndex')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to support the old name, too? Would be cleaner to have a code migration for that as otherwise people will still keep on using the old name and wonder, why there is no corresponding yaml definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi ;) yes good catch ... we do have working migrations regarding eel but fusion property names cannot be that easily migrated ... thus a super slim b/c layer like this might not hurt?
But we should adjust the docs to reference this ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to show an error to developers for this? Sth like:
if ($this->fusionValue('renderHiddenInIndex') !== null) {
throw new Exception(...);
}
I know, this has small performance drawbacks, but I would prefer a clean migration personally, as this could lead to confusion in the long run. And the warning can be removed in a later version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay yes we could go down this road and additionally consider doing a string replace in all fusion files ;)
Thats a good idea i agree. Wdyt @kitsunet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't mind that, I think here was some opposition against throwing errors in fusion implementations as usage can be pretty conditional and you might not notice it before bringing in live.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay i just removed it without exceptions thrown ^^ lets see how we can migrate this 🙈 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh i just found out that the docs must be adjusted as well:
neos-development-collection/Neos.Neos/Documentation/References/NeosFusionReference.rst
Line 1110 in 7faa3c8
:renderHiddenInIndex: (boolean, default **true**) If TRUE, render nodes which are marked as "hidded-in-index" |
And there are still a lot of references to hiddenInIndex
(especially in fusion code, docs and old test code)
The test old legacy test code referencing this name will be removed via my pr here: #5036
if ($this->renderHiddenInIndex === null) { | ||
$this->renderHiddenInIndex = (bool)$this->fusionValue('renderHiddenInIndex'); | ||
if ($this->renderHiddenInMenu === null) { | ||
$this->renderHiddenInMenu = (bool)($this->fusionValue('renderHiddenInMenu') ?? $this->fusionValue('renderHiddenInIndex')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi ;) yes good catch ... we do have working migrations regarding eel but fusion property names cannot be that easily migrated ... thus a super slim b/c layer like this might not hurt?
But we should adjust the docs to reference this ;)
Okay i pushed a few commits adjusting fusion and documentation further. I think there are now no references left. |
…nal-node-properties
This broke the XLIFF files, Weblate says |
Looks like to many |
Fyi we missed to include some followups in the beta10 and might also have to consider providing a core node migration or a snipped to be copied (especially looking at @ahaeslich and her project as well as the docs and @nezaniel starship?) |
🤔 Did you discuss a core migration for this in a recent weekly? I'm undecided here ... How about all those users testing the beta releases? |
Renames
_hiddenInIndex
tohiddenInMenu
.This was done and decided in order to minimise confusion regarding magic
_*
underscore properties.The property
_hiddenInIndex
was such underscore property in 8.3 but as with Neos 9Node::isHiddenInIndex
has been removed. As non breaking temporary replacement it was reimplemented as actual node property except with an underscore prefix:_hiddenInIndex
. This is possible as the core doesn't work with these underscore properties anymore.In Neos 9 there will simply be no magic meaning for underscore properties anymore, any property will now be allowed to start with an underscore. To better communicate this - but not enforce the use of such - Neos.Neos will refrain from declaring Node properties with underscores as this is an overloaded feature of the past and can easily cause confusion.
Fixes partially: #4208
Upgrade instructions
Following Fusion prototypes no longer accept an
renderHiddenInIndex
option but only considerrenderHiddenInMenu
. In the case you overwrote the default behaviour for any of these prototypes you should rename the option torenderHiddenInMenu
.Accessing the property has to be adjusted as well.
Upgrade from 8.3
upgrade from 9.x-dev
Review instructions