9.0 DOCS: Node hidden vs disabled

[mhsdesign]

Previously in neos 8.3 you could hide a node. This is now called disabled (see command)

@bwaidelich described it as:

What we sometimes call “hide” is actually a disable (and that’s how the event is called with Neos 9 and IMO we should reflect that in the UI as well).
I could even imagine, hiding (pun intended) disabled nodes from the document tree by default and adding some kind of “recycle bin” view… But I’m getting side-tracked: My point is that we simply can’t know whether the user…

I would like to have the differentiation and mind shift documented (maybe in the php doc codes) so people can understand ^^

the VisibilityConstraints seem to need docs in general:

neos-development-collection/Neos.ContentRepository.Core/Classes/Projection/ContentGraph/VisibilityConstraints.php

Line 24 in ee36cc2

final class VisibilityConstraints

or maybe here in the command?

neos-development-collection/Neos.ContentRepository.Core/Classes/Feature/NodeDisabling/Command/DisableNodeAggregate.php

Line 31 in 4c9dd08

final class DisableNodeAggregate implements

The general problem might be that integrators are familiar with the term hidden in neos but not with disabled im now conflicted myself how to name the property in the nodeType templates package ^^

So any definition would be welcome ;)

[bwaidelich]

The good old "hiddenInIndex" makes sense => The page won't appear in Menus, but it can still be navigated to.
"hidden" didn't really make sense, because it's not that the page is just hidden and you can find it if you only have the correct URL. That node does not exist (as far as the frontend is concerned) but it can be reactivated.

A bit similar to files you put into the recycler (vs files you hide from the file explorer/finder)

[Sebobo]

IMO we have to be a bit careful with naming and where we use "technically" correct terms and where we use terms that our users actually understand.
Whenever I read CR related technical text, I'm getting quite confused and have trouble "translating" it to the people I help on a daily basis.

Do we have some glossary that we can review and discuss at some point?

[mhsdesign]

Im not sure i get how it all relates together. My brain could manage VisibilityConstraints and DisableNodeAggregate but now im a bit confused by: NodeHiddenState (especially why is it hidden, and why can it NOT answer the question whether a Node is hidden because some node above it has been hidden?)

[bwaidelich]

IMO we have to be a bit careful with naming and where we use "technically" correct terms
and where we use terms that our users actually understand.

I fully agree and I also stumbled upon the many new names and concepts in the new CR.

Do we have some glossary that we can review and discuss at some point?

I don't think so, but we urgently need that on docs.neos.io – I created an issue for that and put it on the project board (#4314)

im a bit confused by: NodeHiddenState

Yes, that name is a left-over and it should be named NodeDisabledState – or better yet, be extended to all kinds of attributes (see #4315

[mhsdesign]

I just found this on docs neos io

https://docs.neos.io/guide/contributing-to-neos/event-sourced-content-repository/enabled-and-disabled-nodes

In the old CR, this was called “hidden”, but we felt that enabled and disabled captured the intent better.

If a node is disabled, the system should behave as if this node would not exist. This means:

• you are not able to query for this node
• you are not able to query for any child node: If you removed the node, all children would be removed as well.
• these rules must only apply in frontend, when viewing the site. In backend, you should still see the disabled nodes, so that you can e.g. enable them again.

[mhsdesign]

Also this is the pr fyi which renamed it to disabled ^^

neos/contentrepository-development-collection#94

[mhsdesign]

@dlubitz and me just wondered how far we would like to take this naming decision. Eg should this also be reflected in labels of the Neos Ui

#4817 (comment)

[mhsdesign]

@bwaidelich @kitsunet @grebaldi and me discussed to align the naming also in the Ui to "Disabled" (at least in english) In german "Deaktivieren" "Ausschalten" ...