Show property for label in tree view(Structure tree)

Hallo,
as described here(see label) I would expect, that as label in the structure tree there would be the property “vehicleid” of my current custom node, if I set the following:

NodeTypes.yaml

'Vendor.Site:Car':
   superTypes:
     'TYPO3.Neos:Content': TRUE
       ui:
         label: ${q(node).property('vehicleid')}

But in the structure tree view ${q(node).property('vehicleid')} is shown. Does anybody know, what I’m doing wrong?

In addition to that:
Is it possible to sort nodes in a content collection in the structure tree by a property, for example by name?
The aim is that an editor is able to find a node as quick as possible in the structure tree - there is no search or filter field in the structure tree.

That is a misconception about how SuperTypes work in yaml. SuperTypes are boolean properties and the Configuration Module should show you that as an error.

Instead try the following:

'Vendor.Site:Car':
  superTypes:
    'TYPO3.Neos:Content': TRUE
  label: ${q(node).property('vehicleid')}
2 Likes

Fine, that works :grinning: Thank you!

Any idea regarding my second question?

Short answer is no … offcourse there are options if you are listening to signals etc. but I would stay away from that until you have a good understanding of the neos-cr.

If you have so much content on one page that editors are confused you should consider to put the content in a document structure that helps editors to find what they need. You still can render the content on one single document in the front end if you like.

…offcourse there are options if you are listening to signals etc.

Ok, thank you for the hint.

If you have so much content on one page that editors are confused you should consider to put the content in a document structure that helps editors to find what they need.

I thought about that already and I think I will do so.
It seems that’s the recommended way to think about content in neos, isn’t it? I understood the general concept as that the editor should be able to edit content “where he sees it”.
In my usecase there is a car dealer, which deals with vehicles. So it would be useful to set a structure tree where the vendor/editor e.g. first “chooses” a brand, then a model and then is able to find the car/vehicle right fast at the content collection/page.

You still can render the content on one single document in the front end if you like.

I did that already, thanks for the hint.

If there is view that shows only a single car make that a DocumentNode and edit the Information there. Then you can add Structure Documents maybe for Brand / Model / Year or whatever you like. That also gives you a nice url-structure and usually editors get that quite soon. In general everything that makes sense to link to should become a Document.

It would make sense to define Document-NodeTypes CarCollection and Car where a Car Collection can contain Car and CarCollection-Nodes. On a Car-Collection a list of teasers for all cars below would be shown and maybe some additional content would be added.

There is also a solution to create such hierarchies automatically https://github.com/sitegeist/Sitegeist.CriticalMass but i would not recommend to use this until you are really familiar with the cr.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.