backdrop
[UX] Make node title a proper (sortable too) field. a.k.a. Title module in core.
Let's correct another D7 annoyance and get Title in core pretty please.
Converting node title fields to the Field API would allow them to be treated as the rest of the fields instead of being special-cased and would also allow them to be sortable in the Field UI.
I don't think putting Title module in core is the correct solution. Title module itself is a work-around because of other core limitations. I think it'd be more appropriate to make the Title field translatable without creating separate nodes, as that is the primary limitation in core. There are lots of special cases for the Title field that make it not a perfect fit for being a field:
- The title field is always required (or needs to be auto-generated).
- The title field doesn't need to be reordered (or I wouldn't expect it to be, maybe I'm mistaken)?
- It should never be multiple values.
If we want to maintain this issue and tackle the primary problem, could we generalize this as simply, "Make node titles translatable"?
Some related issues in d.org:
Make title behave as a configurable, translatable field (again) [#1188394] (closed as "wontfix") Move "Title field label" setting to "Manage Fields" tab [#1513054] Revert node titles as fields [#571654]
...also wanted to point the Title field UI module out:
Allows administrators to configure title fields for nodes from the Field UI. This also allows users to edit the description and field size of title fields, as well as easily disable or enable title fields for a node type.
Similar modules
Title - actually makes titles a proper Field API field compared to this module which only 'fakes' titles being a proper field to allow it to be managed in the Field UI rather than on the edit content type screen.
...allows users to edit the description and field size of title fields, as well as easily disable or enable title fields for a node type.
The edit feature ...I'm not so sure about, but the disable title feature might be what @bd0bd is looking for as part of what he is trying to achieve in #1191 ...although it does what it does on a per-node type basis and does not provide a node-per-node option.
This variant is too complicated. If I need to hide a title on a page then I need to add a special content type page - it is additional unnecessary headache in my mind.
Yeah, I figured it wouldn't suit you. That's why I said:
...although it does what it does on a per-node type basis and does not provide a node-per-node option.
Yeah, I figured it wouldn't suit you.
It is not exclusively for me :) It is for Backdrop users who could easily use this option.
@quicksketch are you still having strong feelings about the title field not being a proper field? Addressing the points you've set previously...
There are lots of special cases for the Title field that make it not a perfect fit for being a field:
- The title field is always required (or needs to be auto-generated).
Normal/proper fields can be made required. Can't they? ...and now with token in core, we can auto-generate titles by using tokens in the default value. There are such use cases where the title is to be hidden from the user and auto-generated.
- The title field doesn't need to be reordered (or I wouldn't expect it to be, maybe I'm mistaken)?
In general yes, but there might be use cases that we simply haven't thought about. Nobody says that if we allow it to be reordered people will have to do it. The option will be there should they need it though.
- It should never be multiple values.
Sure. That one I get, but can't we special-case/override only this thing about it somehow?
If we want to maintain this issue and tackle the primary problem, could we generalize this as simply, "Make node titles translatable"?
Yeah, but if you look at it the other way, if nodes were proper fields, wouldn't they "automatically" inherit field features such as the ability to be translated?
fwiw I'm also against titles being "proper" fields. Another point that no one has brought up here is that tiles are treated specially in template files too. Content is all rendered together, but titles are special as they often precede everything else (separated by authoring info) and get special heading tags.
We're getting into that messy area of UI vs Theme, which one wins?
@quicksketch: The title field doesn't need to be reordered (or I wouldn't expect it to be, maybe I'm mistaken)?
Wow, yes, titles need to be reordered, especially in the Manage Display tab. I've been meaning to add a ticket for that. Right now if you can't move an image above the title in a teaser, so if your design calls for it, you need to print out all the fields independently using views.
As far as the idea of turning the title into a field, that is probably not something that we could change in the 1.x version of Backdrop, since it would likely require making substantial changes to the entity api and possibly every other entity type that is defined.
Is there a ticket for making titles translatable, or should we perhaps just change the title of this ticket to propose solving that one particular problem?
#1944 holds a discussion of what alternatives there are in order to implement this feature.
Keep in mind that we probably can't even add re-ordering in the 1.x cycle, since the title is treated specially in templates, too. It's usually printed out separately in H2 tags, and also surrounded by title_prefix and title_suffix.
I would love to see all these things updated in 2.x:
- make title re-orderable 1a) allow users to choose the wrapper (h2) that goes around it - like we do now in views and blocks
- in the template, print out the title with all other fields as part of $content.
- move title_prefix to the top of the entity wrapper, and rename it to have nothing to do with title.
- remove title_suffix entirely (as it is never used)
Isn't an alternative to reordering to allow titles to be added as separate blocks in a Layout? I've done it in Panels often but I don't see it exposed in Layout for some reason. Maybe this is something that can be done in 1.x?
@herbdool it depends which page you are working on. If you are looking at a node page then the node-title should be the page-title (or h1) and not printed as part of the node "content" at all. At least by default.
If you wanted the node-title to render somewhere other than the page-title you would need to place it on the page yourself, likely by creating a view that takes an argument. You'd also have to come up with another page-title for the page to replace the H1.
In panels there was a class of content panes (blocks) called "Page elements" that included things like Page title and Breadcrumb, and those could be placed. In Backdrop, Breadcrumb is already a block. I believe we also have an issue to make the Page title into a proper block in Backdrop 2.x. This is an even crazier change than addressing the node title as a field, since all layouts print the page title in their template files.
I was just doing it in Panels the other day. Title is also available under Node when adding to a panel content. It also meant disabling the main title so perhaps that was a hack in Panels as well. If so, then it could probably be done in contrib with 1.x.
I needed to do this recently in Drupal 7 because the designer really stretched the extent of what the basic templates could manage.
In the meanwhile it is possible, as Jen said, to create a Views block, add a contextual filter for the node nid and add that to the Layout. You can even override the field html element and css classes by forcing it to be: h1.page-title
In Drupal I use to manage the display with Display Suite aka DS which exposes not only fields but also other stuff in the UI, amongst others you can hide and reorder the title or configure stuff like the title wrapper, which is very useful for my projects.
Important limitation: Display Suite doesn't make the title translatable, but maybe the DS approach can serve as another stimulation how to manage the title.
Yeah, I realize that we can't do this in 1.x, but I already knew we couldn't be avoiding this for ever. Gives us another thing to be looking forward to for 2.x.
Perhaps as already said, we port the Title module in contrib for 1.x, let it develop first and also check usage stats before finally getting it into core.
...looking at our plans for 2.x, having title as a regular field would help making it translatable because it would then inherit all perks that we implement for other fields.
Is anyone worried about the database structure of changing title to be a "proper" field? Won't there be significant performance regressions, too?
Orderable
We could solve this via hook_field_extra_fields(.
Display options
We could solve this via hook_field_extra_fields() and special settings like UI control of the heading tag and classes. (would break template markup if we did it in 1.x)
Translatable
We could solve this separately
Are there any other things we'd get for free by using fields, and do those things have other solutions? I'd like to weigh pros and cons of both ways.
I'm not able to evaluate database structure related questions but wanted to add that the issues of titles not being orderable and having limited Display options are partly solved by the Page title as block feature which was introduced in Backdrop 1.7.0.
I think the main problem to solve is exposing the "Title" to the Manage Display area.
I need to reorder the "Title" of a taxonomy vocabulary so it sits below the font awesome icon field I created so I can show an icon in front of the title. Since there is no way to do anything with the title, I have no way of accomplishing this.
Like mentioned before, DS (Display Suite) would expose these and allow me to handle this on Drupal. Since DS hasn't been officially ported, there is no way to expose Titles in the Manage Display area.
I would say this needs to be approached from two directions
- Make the title field "proper" (I don't think this field necessarily needs to be proper in the sense of the word)
- Expose the Title as a field on the Manage Display page.
If we can get 2) exposed like a field so there is room to manipulate it, then I have a feeling this will take care of 99% of the use-case problems out there. We can wait until 2.x to make it "proper" if there is still need for it.
So: Either core needs to expose title to the manage display page (#2084) or Display Suite needs to be ported to handle this in contrib.
I'll check out the Title Field UI @klonos mentioned in the meantime as a potential workaround.
Update: I think Title Field UI only works with nodes. I can't get it to work at all on Backdrop though so, bust...
One solution might be to only allow the title field to be manipulated on a display mode that isn't the default display mode? Lock it (but still show it) on the default display mode but allow it to be moved around on a custom display mode.
Side note, after some digging, @hosef began working on porting DS over to Backdrop. Commits are a bit old and some things aren't working right but at the very least, enabling DS and DS_UI will allow you to manipulate the Title field for a node. I'm getting errors when viewing Taxonomy term pages so it isn't without problems using taxonomy displays but it does work there too and makes for a great start to this discussion as an alternative.
https://github.com/backdrop-contrib/ds
Update: I managed to clear the errors and filed some issues on the ds issue queue for them in-case anyone wants to use ds for manipulating the title fields.
I'd like to revive the discussion because none of the mentioned workarounds would solve an issue with Existing content blocks. This was a blocker of a favorite approach for the new hidden-path content type (Cards) in core:
Out of the box, it's not possible to place the Image above the Title in the Existing content blocks.
These are not trivial changes - it will involve changing entities and templates.
I think the solution of using hook_field_extra_fields() that @jenlampton proposed is the most architecture-friendly and would require the least amount of change (it would, however, require changing the core templates). Making titles into Field API fields is really a major departure from the current architecture.
Making titles into Field API fields is really a major departure from the current architecture.
I see! This sounds plausible from a technical point of view. From the perspective of a site owner / site architect, the limitation seems however strange, not understandable, and in some cases it's hard to work around. It's not user friendly at all, i.e. not Backdrop like.
I haven't really thought through the idea, but wouldn't it be possible to do such comprehensive changes only for new installs? That would allow to approach it before Backdrop 2.x.
Let's put this on the agenda for the next UX/Design meeting, but encourage folks to think about it before that.
I think that we sometimes come up with solutions during meetings that we might not come up with in issue queue discussions alone. Bummer, we didn't think to talk about this today.
it would, however, require changing the core templates
This is why this issue is tagged with the 2.x milestone. I think it's important but might make a mess of things for front end devs if we tried to do it in a backwards-compatible way.
The title field doesn't need to be reordered (or I wouldn't expect it to be, maybe I'm mistaken)?
In a twist of fate, I had a recent project that needed to move the title field on pretty much every teaser and card version that was displayed. And I ended up writing a contrib module for this need: https://github.com/backdrop-contrib/title_display
I wanted the ability to order and configure the title field (such as using a different level of heading tag) but without the weight of Display Suite, since this is the only feature needed from that collection of modules.
Perhaps I should have reviewed or ported Title field UI. But this new module is simpler (I believe) in implementation, since it does not attempt to modify the display mode form so much.