Where do you go to change the lablels on all the fields on your node form? Well, for every single field except one, you go to the "Manage fields" tab for your content type. I know title is special, but if we want people to be able to find this setting intuitively, we need to move it to where people will look for it naturally :)

move the title field label setting to the manage fields tab

Files: 
CommentFileSizeAuthor
title_field_label_manage_display.png121.72 KBjenlampton

Comments

karschsp’s picture

Seems like this would be really easy/redundant if we could get this in: #1188394: Make title behave as a configurable, translatable field (again)

Bojhan’s picture

Status: Active » Closed (won't fix)

Yup, it simply has to be a field - its the only thing that isn't and that is super weird.

mattys’s picture

agreed!

jenlampton’s picture

Status: Closed (won't fix) » Active

No, it doesn't have to be a field.
It just needs to have hook_field_extra_fields() implemented, so the settings *appear* in the place people expect it to be.

groovedork’s picture

Yes, it so totally should be a field.

I've created projects where I didn't want a title (used Drupal as the engine for an (award winning) urban game), and I had a hell of a time trying to get rid of the damn thing. The NodeID should be the underlying unique thing about a node.

The title should be a field like any other, and should be removable like any other.

Pancho’s picture

Title already is a field, but a base field rather than a configurable field.
A UI for adding some of the settings known from configurable fields to non-configurable fields, is underway, but at risk of missing the deadlines, given there's still so much to do. So it's good to keep an eye on it.

Removing the Title field label from the main content type configuration means the title label wouldn't be changeable anymore without Field UI being enabled. I'd argue that this is okay, because it matches the Body field, because it's certainly not the 80% use case and because more advanced use cases will - at least in the dev stage - use the Field UI or will do things programmatically. So from my perspective a +1.

We'd need to figure out which of the remaining Field API issues this one depends on, and help there. The actual removal will be the easiest thing to do.

crutch’s picture

Just want to add, and this may have been covered somewhere, and this may be already considered when converting the title field to a configurable field at some point...

...a description for the Title field is very much needed.

Right now, we have to add instructions for the title field in the Body field description which is way down below the Body box and the Input Format box which they end up never seeing it.

The other way to achieve a description for it currently is to add a longtext field under the title with a default value. So what we end up with is an additional textarea field where we can only use plain text. Then not display that field.

You would think a Title is a Title but 75% of the time that is not the case for us. When there are many content contributors, and to achieve some consistency when constructing the Title, it needs a description/help field directly under it.

yoroy’s picture

Version: 8.0.x-dev » 8.2.x-dev
Issue summary: View changes

Still makes sense to do this.

Bojhan’s picture

Category: Feature request » Task
Issue tags: +DevDaysMilan
Cyberschorsch’s picture

I checked this issue and thought about a possible solution, but I am afraid this will not be easy.

- The "title" is actually the "label" property which is an entity key
- The "Manage Fields" table is a "ContentEntityListBuilder" table which means that every row we display there is based on a config entity (field_config)

Any idea how we can get the title field in there? I think the right way to go would be to make the "title" an actual field...

crutch’s picture

Maybe have the option to be able to designate any text configurable field to copy to title field. If and when the text config field is used to copy to title field, then the title field is not displayed for admin and end user.

This will allow other modules to still play nice with the title field, like panel variants, feed imports, etc.

For me it would be important to keep the xpath parser for feeds that depend on the title. "Field title is mandatory and considered unique: only one item per title value will be created."

For other configurations the title field should still then process the unique url for duplicate text/title entries.

http://site.com/my-page
http://site.com/my-page-0

Gábor Hojtsy’s picture

Maybe I don't get what you are suggesting but it sounds like a hack that would not really solve the problem but introduce new ones? :)

DYdave’s picture

@crutch
If I'm not mistaken, I think what you would be suggesting is very interesting, but maybe already exists?
Do you think this could be what you would be trying to achieve: Computed Field, Automatic Entity Label, Automatic Nodetitles or : hiding the title and setting it to a generated value based on a user defined pattern (making title values unique could be achieved though patterns, with time, ID, etc... for example).

I think the approach discussed in this issue is more fields related.
More specifically, I think an important part of the work would be to align title's field configuration on other fields' (for example, content "Body"), as such an obvious example would be to remove its config form from the Edit Content Type pages (see the summary for more details, see screenshot).

Just a thought, but this is perhaps something that could be developed in contrib, as a first step, catching back on #10 which brings some interesting questions.
I haven't looked into this yet, but I'd be glad to hear more technical advice about this, in particular from fields related core developers.

Thanks in advance to everyone for your feedback and comments on this issue.
Cheers!

crutch’s picture

Yes thanks Dave I ran into some issues with those modules and had to uninstall them. Re: creating the title from a text field. I haven't tried computed field module though.

Agree it should eventually be core functionality, configurable field, and not be a workaround module @#12.