Skip to content
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

Open
wants to merge 11 commits into
base: 9.0
Choose a base branch
from

Conversation

kitsunet
Copy link
Member

@kitsunet kitsunet commented Mar 6, 2024

Renames _hiddenInIndex to hiddenInMenu.

Fixes partially: #4208

@kitsunet
Copy link
Member Author

kitsunet commented Mar 7, 2024

unrelated errors 🤷

@bwaidelich
Copy link
Member

unrelated errors 🤷

@kitsunet Fixed with #4924 and rebased

Copy link
Member

@bwaidelich bwaidelich left a 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?

Neos.Neos/Classes/Fusion/Helper/NodeHelper.php Outdated Show resolved Hide resolved
@ahaeslich
Copy link
Member

You mentioned that there are follow-up todos for Neos UI?

Looking at this PR I noticed Neos.Seo may also need adjustments. So checking our codebase I see that:

  • the legacy migration should rewrite hiddenInIndex to hiddenInMenu
  • translations must use the new name
  • the UI uses _hiddenInIndex
  • there are comments referencing the prop
  • our rector package needs adjustments
  • Neos.Demo needs adjustments in fusion and with the exported content

ahaeslich added a commit to neos/neos-seo that referenced this pull request Mar 10, 2024
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
@kitsunet
Copy link
Member Author

Rector btw. is here neos/rector#45

@kitsunet
Copy link
Member Author

  • the legacy migration should rewrite hiddenInIndex to hiddenInMenu
  • translations must use the new name

@kitsunet
Copy link
Member Author

These testfailures seem again unreltaed?

@kitsunet
Copy link
Member Author

kitsunet commented Mar 11, 2024

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.

@kitsunet
Copy link
Member Author

FYI: Karsten said just renaming the labels should be fine.

@kitsunet
Copy link
Member Author

Neos.Demo: neos/Neos.Demo#192

@nezaniel
Copy link
Member

I'd like to help here but can't get PHPStorm to detect the merge conflicts...

@kitsunet
Copy link
Member Author

I can try to get it back on track, somehow I thought iut was long merged 🙈

@kitsunet
Copy link
Member Author

neos-ui change: neos/neos-ui#3735
this fixes disabled tag export as well

@nezaniel
Copy link
Member

what parts are still missing here? All that I can see looks very nice already

@kitsunet
Copy link
Member Author

what parts are still missing here? All that I can see looks very nice already

Nothing IMHO, it should all be merged please 😆

@mhsdesign mhsdesign self-requested a review April 25, 2024 08:34
Copy link
Member

@mhsdesign mhsdesign left a 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.

Copy link
Member

@nezaniel nezaniel left a 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

@mhsdesign mhsdesign force-pushed the task/4208-remove-internal-node-properties branch from 05e6552 to 565bff1 Compare April 26, 2024 08:10
@mhsdesign mhsdesign changed the title TASK: Remove "internal" node properties !!! TASK: Rename _hiddenInIndex to hiddenInMenu Apr 26, 2024
@mhsdesign
Copy link
Member

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 hiddenInMenu part.
@kitsunet i think we might need a better description yet (also maybe for the WHY we did this).
Rector seems already to be adjusted: neos/rector#45

Followups:

Copy link
Member

@mhsdesign mhsdesign left a 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'));
Copy link
Contributor

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.

Copy link
Member

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 ;)

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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 🙈 ?

Copy link
Member

@mhsdesign mhsdesign left a 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:

: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'));
Copy link
Member

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 ;)

@mhsdesign
Copy link
Member

Okay i pushed a few commits adjusting fusion and documentation further. I think there are now no references left.
This is now even more breaking as there is no fallback layer in Fusion thus we need a good upgrade instruction in the pr and maybe rector?

@mhsdesign mhsdesign requested a review from mficzel May 10, 2024 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants