As a follow-up on some discussion(s) we already had in the last years about how to deal with the hard coded view of the misleading named "title" (entity label) base field on entities and the already running [META] issue working around some of the issues with it, I came to a possible worth-to-discuss idea I can't find a duplicate issue or META for yet in the issue queues. To not "work around" it, but to make it conceptually clearer and more useful in the sense why we had this base field and why it was required.
Users more often than expected think that they actually do not need a mandatory (required) entity type > label (f.e. "title") field in all use-cases, so that we always had a hard time to explain why we still "need" it for many reasons (e.g. referencing). But what is it what we do need on it exactly? Reading all the issues discussing this aspect makes clear that there is something upsidedown: We rather need a field serving as a label instead of a label serving as a base field (Look at Paragraphs or ECK). What I mean by that is, that no additional base field is needed, but a mandatory choice to make which field will serve as the label with the label functionality combined, for a given field already setup for this entity type. This prevents having additional and sometimes meaningless label fields around on created entity types.
In my understanding of content modeling by fields (which is somewhat similar to data modeling in general in many of the visible aspects) a fixed field type namely "label" is actually not a usual mandatory base field, like unique node_id is, or like date_created or date_modified or authored_by is. I think it was a work around to have something "readable" in place serving as label? We rather should give the option at hand to choose a proper field type (depends on the use case) in the entity type creation form as a "label" for the entity/content type instead. And we should explain in the description of the checkbox/radio why this is mandatory and required to choose one of the fields created on the entity type to serve as label.
As an example: The content type "Article" in the default Drupal installation profile could show some "headline" field with a ticked checkbox "use as label" to demonstrate how it works, which can be changed/reversed by the user (but only as long as no content or reference has been created).
This would solve so many issues with the entity type label base field conceptually and would stop confuse users in so many use cases, that I cannot stop thinking about it. Even if it makes no sense or has issues which make it impossible to realize this idea. (Let me know please).
This way the required readable "label" of any entity type like content type isn't a fixed base field no more, but it is a required choice to make (setup to make) and an additional title/label field misused as base field isn't needed no more. Any proper field type already set up for this bundle can serve as the label, e.g. on references or automatic listings, etc. And contributed module projects like "Automatic entity label" or "Unique title field" aren't required no more since we do have already projects on D.O. checking unique field values or autofill fields from Tokens or Twig variables (but not for the label).
The same goes for the "name" field on the media entity types or the "title" in custom blocks. We should leave it to the user to choose a proper field type as the readable “label” for it and should make a radio / checkbox "use as label" in the field creation form or similar available. The flexibility raising from it would be endless.
Some field type creation forms will have an additional checkbox/radio, like "use as label" which can only be ticked once in a entity type creation form.
Maybe this requires also API changes since we maybe run hooks against the former base field "label" on several places?
There will be no base field serving as label no more, but a choosen existing field in the created entity type serving as "label".
NOTE: I am not sure if it possible to run such a change in an experimental version, since the change is too drastic in the whole installation.
Comments
Comment #2
dqdComment #3
jonathanshawEntities need labels for many admin purposes, so a field must be provided OOTB to serve this purpose for node.
If a custom or contrib module wants a different field to be the label, that can be done by swapping out the entity class and overriding the label() method.
If you want a GUI to choose the field to act as label, a module could provide that. It doesn't seem to be a common enough need to fit the 80% use case that core seeks to serve.
If a project doesn't want that title field at all, it can be removed programmatically very easily.
I think core is fine as it is. Unless I'm completely misunderstanding.
Comment #4
dqdShort: Exactly, but it isn't mandatory that it is EXACTLY THAT field. This is exactly what this issue is about.
Long: Thanks for your thoughts on this @jonathanshaw. This issue is a follow up from many other issues discussing this topic and there are already issues with progress on alternative solutions for core. Are you aware of them? I just want to prevent a fall back to the initial topics here since I actually hoped to create a secondary line issue here discussing another way around. Basically you are right and I thought I have stated the same point in my starting post you made about the basic need of such label. But maybe I didn't made it clear enought since english is not my native tongue. The need is what most contributors agree on, including me.
But how this is solved at the moment is where many opinions have raised over the years. And I missed the one, which discusses the solution to force the user to choose a unique mandatory field as label in the state of content or entity type creation. This way we prevent many aversions regarding the label and we sharpen the understanding what this label is needed for.
Comment #5
dqdIf you look at the project automatic entity label, then you will see: it is what this module is exactly doing.
It gives you the option at hand to choose which field will be the label of this entity type and hides the original title field. And when you look at the count of downloads and usage statistics, you'll see that this is something worth to discuss. In my porposal we would give this option immediatley in the process of entidy type creation at hand, and would prevent the clutter of an additional hidden field. And the good news is: The default basic installation profile of Drupal core can keep as it is and can serve as an example where the unique text field named title, is the choosen label for the content type article and basic page.
The flexibilty would raise one more time...
Comment #6
xjmComment #7
dqdComment #8
dqdComment #9
dqdComment #10
dqdComment #11
dqdSorry for the noise. I had to fix some phrasing issues ...
Comment #12
dqdComment #13
jbitdrop commentedTBH, I even do not understand the requirement or enforcement of the label on ANY entity type. Isn't it the main cause of all issues with it? And from what I understood, custom ECK do not even need it? Is it something special on how we decided a content or media type should be structured and used? Or is it a hang over from how things used to be linked before? Since it does not need to be unique nor does it has checks against special chars or anything else useful to use the value internally I do not understand what else a bundle needs than a unique ID, timestamps and a list of user references who have edited it. Even for revisioning...
That being sad: +1 from me for this! At least one step ahead.
Comment #14
geek-merlinThanks a lot @diqidoq for raising this, and caring for AEL! The IS is a bit confusing to me so may need some sharpening.
Let me phrase it this way: Yes having a getLabel() method is part of the Entity API and for good reasons. Having a title field is not mandatory and often the title field is simply in the way.
In fact i did a few of the 34k usage count of auto_entitylabel, and in all cases it was to in some sense get rid of the title field. Typically you want something like: Let a nodetype's label be Event on {{field_date}}
Let me sharpen the proposal:
* Convert the title field from a base field to a configurable field
* Add a TwigLabelProviderTrait with a configurable twig_label_pattern and use it for Nodes
* Default node types' twig_label_pattern to
{{ title }}This would obsolete most usages of auto_entitylabel (in fact all that i had)
Comment #15
dqd@geek-merlin: thank you very much for your time and thoughts on this! Very much appreciated.
From what I understood ATM (2:33 AM at night with quarantine koller) this is the main motivation behind my proposal actually, but I wanted to "play" a little bit around with the view angle on this ;) - The rest must wait until I wake up again :-) ...
@jbitdrop: thanks for chiming in, but...
... not as easy as you may think. It's not only history related. But the fog/mist will clear over the next comments. Just follow the comments of long term contributors to the Drupal project, if they find time to chime in. It is indeed a little bit tricky.
All the best to you all and please stay safe!
Comment #16
imclean commented#13,
See #2785297: Allow fields other than title to be used as the entity label.
Comment #23
dqdTo get this issue out of its theoretical state and to help make it more understandable what I am after here let me put more concrete possible changes to be made on the table what also underlines the paradigm change needed better maybe.
As we can see in the active issue queue regarding references and reference form field widgets (I saw them coming ;-) this is an issue on a huge scale and that is the reason why my OT here was so long. :-) In case we go that route proposed here to make any field created on that entity bundle type available to choose from as the defacto label of this bundle we need also to consider another way we internally check for the choosen label. Because we can not know OOTB which one it is or cannot create a list of all possible to "knock on" if it is the label. The choosen label field need to have an own "type register" or "method to get detected as label" where to look at for fields choosen as label on that bundle. Which brings in a complete new and more flexible way for reference form fields to fetch or display or select on lists etc.
A good example (other use case but similar premise behind) can be seen here where the proposed (and correct) solution is to rather use getkey instead of targeting an assumped key. #3366392: Get Bundle Field Name from Entity Definition
Comment #24
jonathanshawThis issue remains hard to understand, many words but few technical details.
The label is defined in 2 places AFAIK:
(1) the label() method on an entity, which is overriddable by swapping out the entity class or bundle class.
(2) The label key on the entity type annotation which is shared between all bundles of an entity type. It provides the default user by the label() method, as well as being used in queries like autocomplete queries.
So if there is a feature request here, it sounds like either:
(1) make entity keys (or at least the label key) overriddable at the bundle level
(2) provide a UI for configuring the label on a bundle
Probably (2) depends on (1) anyway.
(1) profoundly changes assumptions about the data structure of Drupal entities. To ensure BC we would have to replace the getEntityKey() method with a getBundleKey() or at least add the latter. And this leads to complications - possibly insurmountable - when querying across multiple bundles.
Fundamentally I think this issue is wrongly targeted. Its focus should be on making it easier for entity autocomplete in particular to query across fields other than the entity label. The problem is not the entity label data structure, it's with autocomplete's narrow focus on the label.
Comment #25
johnpitcairn commentedIs this about entity reference field autocomplete?
If so, what's wrong with the established technique of using a view to provide the entity suggestions. That does allow you to specify the entity fields to search on.
Comment #26
jonathanshawYou're right. So my retitling was a mistake.
We can already specify any field we like to be the label, so the IS is misleading.
The feature request here has to be: Allow entity keys to be definable/overriddable per bundle per #25.
But this is a big change in the architectural model for a small gain, so I have to think we should close as won't fix.
Comment #27
dqdOne does not automatically lead to the other. Some people have trouble to follow long texts and this is why the task to shorten the OT has already been agreed on. And "Few technical details" was on purpose because it was rather a "brainstorming" and idea about to change the handling of title/label key fields before starting tasks.
Apart from that: Thanks for joining. There are many possibilities for misunderstandings. Conceptually and technically. And also on my side for sure. But please do not change the title immediately from your POV without discussion what this is about here. As agreed on already in #14 and below: the summary is long and maybe not clear enough for some readers. And so maybe your assumptions what it is about. The OT summary is too long as already discussed earlier and I was about to change that, while this issue now feels slidely hijacked and from the original purpose more and more drifting (maybe).
All your good ideas regarding "what it possibly means technically to change for that" are possibly right and maybe part of good follow ups (tasks). But this issue needs some work on the OT from the original poster before we can discuss its tasks or possible confusions in it.
Best points until now have been made in #13 and #14 so far.
Comment #28
dqd(1)
(2)
(3)
(1) No. No target yet despite of thinking loud about that the users experience on nodes to be forced with an otherwise useless label key field which acts as the node title in the most installed standard profiles, maybe do not need to be replaced/removed but only be able to be chosen from created fields on node types, so that this field is not "wasted".
(2) There is already an issue for that ;-) And I am not 100% sure yet but I think it was even me creating this one too. And both issues run side by side and basically most thoughts of this issue here lean forward to the other as explained in one of my last comments.
(3) As I sad, this is one way to come close. The other way is to not rely on one special field created only for that purpose, but relying on a flag on a field stating that this field is the label now, as explained multiple times above in other words.
Comment #29
jonathanshawThis is already the case. The 'label' key in the entity keys section of the entity annotation defines which basefield is the label. There is no requirement to create a basefield specifically for the purpose of being the label.
For example, the title field is the label field for the node entity, the id field could perfectly well be the label.
I am not clear from the comments in this issue what about this is insufficient.
The way the current approach is architected means the selected field must be a basefield, it cannot be a diffrent field on each bundle, such as a configurable field. If this is the concern, then the feature request here seems to boil down to: Allow entity keys to be definable/overriddable per bundle.
Comment #30
dqdThe OT ist not "misleading". The starting date of the issue is some years ahead. Maybe I missed something lately which makes the whole issue already obsolete.
@ #29: Thanks for trying to clarify your thoughts. As stated above (before): I will investigate in the next spare time on possible misunderstandings and on sharpening the idea discussed here. Plus: There is a big chance that I am not aware of that this issue already run far out of date.
Comment #31
dqdMany things have changed over the years already. And the standard install profile of Drupal core - which was somewhat unspokenly the basis of this issue attempt - will maybe become less important in the near future. Especially with the starshot initiative getting momentum. So, many of the thoughts in here can be considered outdated. Or rather "absorbed". In a positive way.
To clarify: Most of the misunderstandings in here in between were mainly caused by the fact that the IS tries to cover the "no-code" impressions from average users UI perspective on a standard install profile. While some participations on the disucssion are referring to ways to change that in code or non standard profile scenarios, f.e. custom entities and such.
Misleading or not, maybe too non-technical in some aspects, also, yes, and last but not least too theoretical and mostly based on the assumption, that users are rather familiar with creating node types and fields on node types like provided in the standard profile, the idea behind all this has been somewhat absorbed already in different evolutions of the whole Drupal concept and eco system over the years. Users get more and more used to custom entities. And the understanding of fields, base fields and labels evolved.
So, after thinking about it for a while now, if it makes sense to invest more time in here to clarfiy or narrow the idea into a more understandable concept, while parts of it are already "fixed" in other ways, I came to the conclusion to close this issue as outdated.
In case some of it could need further discussion it would rather make more sense to create a new issue to prevent wasted efforts of users reading all of the previous content, which is obsolete now.