Make title behave as a field (again)

In the Title module we are facing more or less the problems summarized in the other's issue OP and fully described in the attached spreadsheet: the approach taken follows a proposal by @chx to leave the $entity->label field as a plain property and override it at load time with the proper translation taken from $entity->label_field. This can work in contrib but it would be a horrible hack if it were in core. The main pro of this solution is that we don't need to care much about most of the problems cited above, the big con is that it's an inherently fragile approach that might break as soon as one needs to act before a translation is switched in. The storing process is even more convolute and failure prone, since we need to use the value in $entity->label on programmatic saves, but on the same time we need to use the value from $entity->label_field on submit, since the Field API widget is used to enter the translated value.

I still think that we should treat labels as regular fields, i.e. they should follow the usual field workflow to be displayed (load, build, render), instead of being slapped in the page through a simple check_plain($node->title). The main argument against this was that we want to be able to make a simple query to list entities by title, but in the real world we use Views and, if I'm not mistaken, Views perform an entity_load() to display entity lists, hence I don't see this as a performance regression.

Another concern was about DX: we have entity_label($entity_type, $entity) that is perfect for any use of labels outside the entitiy view context (breadcrumbs, administration pages, ...). Moreover, if what we talked about in the entity BOF in Chicago comes true, this will become $entity->label() which is simply beautiful from the DX perspective. Obviously we will need to be able to convert a field value in a plain string but I don't think this is a major probelm.

Can we move over one of the latest patches from the existing issue(s)?

As discussed in #1233394: Agree on a property naming pattern, retrieving an entity's title may no longer be a problem as tough as in D7, as it looks like we're going to move to proper entity classes as well as proper getter and setter methods for entity properties and fields.

Essentially, we also need to do the same for the author and status properties. Different issues, but pretty much the same challenge.

@plach: on properties, fago had some good looking plans presented in London. See the video from 38th minute at http://london2011.drupal.org/coreconversation/unified-entity-api-part-co... (the talk before is also interesting to put it into perspective). Would be great to figure out how do we want to achieve our translatable properties :) @fago's point is that properties should look the same from the outside as fields on the API level.

Marked #618316: Are menu titles plaintext or HTML as a duplicate.

I think this should be totally postponed to finding a solution for translatable entity properties.

I really think it should be a field. I've been in the situation Gábor mentions above where I don't want a text field for the title. I'd rather have an integer/date/etc.

Maybe we can find a quick route / fall-back to getting the default language's title in a hurry without going through the translation system (to keep that query simple)?

Some thoughts on how to do this if we do make it a field:

1. make it either its own field type which is UI-locked, or a particular text field which is created by core on install
2. introduce something in hook_entity_info() where entities can specify fields they have built-in. Therefore most core entities will demand a title field, and it can't be removed by the user.
3. to get round the performance problems, add a second field storage module to core that stores single-valued fields as columns in the entity table.

Tagging for the content handling leg of D8MI.

I think this issue title and summary is too vague. In #1346214: [META] Entity Property API, the goal for D8 is for all properties to behave like fields in some ways. Is there some sense in which title needs to be even more field-like than what's covered by that issue? Or nervousness about the risk we won't finish that issue in D8?

Also, I commented on #1498674-4: Define node translation schema that I don't think this issue should hold up that one.

then it's not really clear to me what the actual difference between fields and properties will be

From what I can tell, even in #1497374: Switch from Field-based storage to Entity-based storage, fields can still be:

• Multi-valued
• Shared across multiple entity types/bundles (at least across those that use the same storage backend)

I think those are the distinguishing ways in which fields are more feature-rich properties. Those requirements lead naturally to storing fields in per-field rather than per-bundle tables when using sql storage (core's default). And I think that default storage decision leads naturally to a desirability (for performance) to sometimes load $partial_entity objects (containing all properties but no fields), which leads to a bias to making properties that are seen as fundamental to the underlying nature of the entity as properties rather than fields (and traditionally, node title has fallen into this category).

We also currently have a UI for administrators to add fields, but not properties, and while when a property API is in place, nothing will prevent us from expanding that UI to allow administrator-created non-field properties, I don't know that anything will compel us to do so either.

One difference between properties and fields that has not been mentioned yet is that fields may be multi-columned: in D7 Title provides an API to replace properties with fields but cannot perform the mapping automatically because it has no way to tell which is the column (columns?) holding the value to be put in the plain property. I think the difference between the two may be summed up in the fact that fields may be multiple compound values, while in D7 properties are essentially single values. Yes, they can hold arrays being serialized at storage time but I'd say this is an edge case.

However, @effulgentsia is raising valid points to be discussed in #28 but I feel this issue should specifically focus on the label topic. AAMOF while labels are currently properties, they also have a whole bunch of specific usages that plain properties don't need to care for: depending on the context a label may be used as an administrative item (e.g. admin-side entity listing), a navigational item (e.g. breadcrumb) or pure content, possibily containing markup (e.g. page title). Not every entity type might need the last two usages, while the first one is probably required. The first two usages require a plain text value, while the third might accept a rendered value.

The default label implementation could be backed by a (translatable) property, but we might introduce the possibilty to designate a field as a "label provider" instead of the plain property. The Entity interface should expose a method to get the entity label as a plain string, it should be responsibility of the label provider to implement a to-string functionality. We should retain the capability of having computed labels (in D7 we have the 'label callback' in entity_label()), which might not even need to be translated. For instance, an event date might just need to be localized on the fly, but a value shared among all the entity translations should be enough. This flexiblilty should free us from requiring an actual storage column for the label, which would be available only where it actually makes sense. In this scenario, the pure content behavior could be implemented on a per-entity type basis, if ever needed.

@plach suppose in any case we need a some config storage (or just code) to configure a callback. For example title could be biulded from tokens so label callback should use some config/variable per entity(type) to store this setting

I was not arguing that we should keep the label callback in place, I was simply saying that we need to keep the ability to have a compute label for the uses cases mentioned above. Maybe simply overriding the Entity::label() method would be fine. As an alternative, we might use computed properties, possible?

Also, on the list of usages "kind of" specific to node title, I'd like to add autocomplete lookup.
The current label() callback, that implies that node titles can only be determined at runtime after load, basically forbids any autocomplete mechanism - see #1194086-42: Real Name not working for user references

If fields & properties storage is managed by the same entity storage provider, and both are displayed through widgets and formatters, then I'm not sure how properties remain more lightweight (memory and CPU-wise) than fields - which was the main reason to keep to separate concepts initially.

1. If Drupal's default storage implementation is for a SQL database, and involves having entity tables (like {node}), and stores some single-valued properties in columns on the entity table, then entity queries limited to just those properties can be performed without an expensive JOIN. Per #33, autocomplete is one of many examples where we want entity label / node title to benefit from this.

2. If some single-valued properties can be rendered without the theme('field') wrapper (or use a variant of it designed for single-valued), they can be rendered faster, even if they use the same item formatter.

So, while we can evolve the entity system to a point where the terminology/concepts of property vs. field go away or are significantly changed, I think our experience in recognizing that some properties are better candidates for being single-valued and by default stored in the entity table, still applies. Maybe that will go away once Drupal's default entity storage engine is not SQL based, but I don't think that'll happen in D8.

@effulgentsia: we don't need this issue if done we can solve translating any property in other ways. We can just as well move on to #1498634: [meta] Define revision/translation SQL schema for core entities (no patch) which is the current discussion for property translation. I think @sun believed that title should be a field in any case, so we did not close this one, but we are really interested in one good way to translate title. If we have property translation in additionally to field translation, whether title is a property or field is just a technicality.

If we have property translation in additionally to field translation, whether title is a property or field is just a technicality.

From the D8MI perspective I fully agree.

In that case, postponing this. But if someone has a reason to unpostpone it, please do.

Well, this issue is not specifically about label translation: here we have a good chance to define more precisely what an entity label is and how it is supposed to work, which in my mind is more or less covered by #29. I'd like to reopen this once we have a proper Entity storage API in place, which should enable us to address the issues cited above in a storage-safe fashion.