[META] Expose Title and other base fields in Manage Display

Found this issue when tried to use view mode of my content type in custom view with some nodes. So, can't do anything with title. It appears anyway.
So, out-of-box I can't work with custom view modes (and even teaser f.e. if I don't need title there).

The page title is now a block

But this issues is not about PAGE title, but about the problem that Title does not appear as a field in Manage Display.
As a result I don't have full control under custom displays for any content type. In any display, title is on the top of other fields and I can't disable (for example if I use teaser display in view and don't need title there) title in display.

Could you please provide ways how I can around this limitation of core? Should I install custom module (like Title ) or there is another way?

Thanks,

Re #4:
What about this? #2605958: Allow page title to be hidden (per page setting)

Not sure how #2605958: Allow page title to be hidden (per page setting) will help us to manage position of title in different displays.

I am only trying to help! In #4 you mentioned that not being able to hide the title is a problem for you.

I have linked to this issue from #2476947: Convert "title" page element into a block, so maybe some of the people that worked on that can add to the discussion.

This is related to Entity API and specifically how the Node entity type is implemented. It is not really related to "page title as block".

I also believe there already is an issue for this. swentel and yched would know.

See? I knew somebody would know more.

@cilefen :) I found this issue thanks to your comment on #2476947: Convert "title" page element into a block.

I found that if I use Title module then I can manage position of title in different displays.
Also I found on the module page phrase "This module has been included with Drupal 8 core." and this issue https://www.drupal.org/node/2607758

@chegor You can manage the display of the title with respect to other blocks, because the title element is now a block (which is great!). That includes suppressing the display of the title on all entities or by role/entity type/page, using the normal block display options. That's the part of the Title module that was integrated.

However, because the title is not a configurable field, you can't move the title with respect to other fields -- you can't, for instance, put the title after other fields, and as the original report notes, it doesn't appear on the display settings for a content type. That's the part that it looks like Title module's 8.x-dev version is allowing.

However, I'm actually sure how this would work now that the title is a block -- if you could move the title-as-field into the middle of other fields, what happens when you move the title block somewhere else on the page?

But I agree that the title element not behaving as other fields is confusing, and in fact has always confused people in earlier Drupal versions.

(Edit: Clarifying the Title module role.)

That's because the display of the title field is hardcoded in the node template, along with the specific logic (when to display, wrap in a link to the node main page).

Since this is hardcoded, the display is specified as "not configurable" in the field definition in Node::baseFieldDefinitions(), and thus does not appear in the "manage display" UI.

#16 Right, so, the question is: Can we change that? Either in contrib (for 8.0.x), in 8.1.x, or in 9.x? Or is there some larger reason that it needs to be hardcoded and wouldn't be possible to make more flexible?

How does Display Suite in D7 override this functionality? Because enabling a template on a content type with Display Suite does allow you to move around the title with the other fields. Maybe that's a place to start.

In my opinion, there's two title types to consider here:

• where a page is a fieldable entity type (for instance a node or a taxonomy), the title should behave as a field and should be manageable as one, not hardcoded in its position. Same goes for other elements as pointed out by iantresman (although that's already available using Display Suite)
• where a page is not an entity type or has no manageable fields - for instance a view - the title should be part of a template and/or a block, as already solved in Core now

For what it's worth the current dev branch of the title module (https://www.drupal.org/project/title) alters the node entity type to make the title base field display configurable. It also takes steps to hide the hard-coded titles in the node template to allow users to configure it in the manage display interface with no duplicates.

Given the hoops I had to jump through to make this possible, I don't know if it will be the final implementation. An extra field may have been cleaner, but it does solve the problem at hand.

I'd love exposing it and killing that hard coded title there, a step closer for DS to die in contrib :) see also #2528314: template_preprocess_node() does not add cacheability metadata (comment #8)

Feature request, so bumping version

i don't understand how this slipped by the core maintainers.

This is by far one of the most frustrating issues with Drupal and one that can confuse site builders.

Please consider adding to Core.

Enabling the Title module (mentioned in #20) has given the desired functionality, although it's currently buggy when using any custom display modes.

I would encourage consideration for this to be in core; my use case of placing and article's title underneath a thumbnail image is a common layout technique to increase readability on news-based sites.

Boatloads of prior discussion at #2010930: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title) and #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title.

Chances of this happening during D8 are very slim. This is an enormous can of worms to untangle, with >10 years of legacy to unravel.

I would like to add my vote for #25 as we do need to be able to very "simply position" title after a thumbnail field at least in the teaser view mode.

Thank you all!

@iantresman ^^ dev branch of Title module is your best option, even if its buggy
welcome to the island :)

Dev version of title module does not work for me, title block still shows and field does not.

I also agree with #25, it seems as though this functionality should be in core.

Just stumbled upon this very same issue.. this kind of renders view modes pointless unless you wish to always have the title in top.. for instance in views displaying a list of node teasers would only work if you want to have the title as the first field..

Can't believe this hasn't been considered..

I understand that for node pages you can use the block, but even placing the block in between node fields is hacky and requires calling for the block from within node.html.twig..

Why not just be able to modify the title field visibility and position among fields in the "manage display" and that way have the possibility to either not display the title in the fields or not use the title block..? And if you wanted I guess you could use both..

Can't believe this hasn't been considered..

That is what this issue is about, no? Definitely, make suggestions. Patches are preferred. See #27.

cilefen: By that I meant that it wasn't considered in core development before this issue.

If I would be pointed in the right direction regarding how to make a patch I'd give it a go. And in what files to look for the this particular functionality.

Also #27 states that this issue would be a lot of work to deal with, but for some reason I remember title field being placable in the view mode editing window in D7.

I just ran into this issue as well while creating a new Drupal 8 site to replace my D7 one. This is a huge issue for me as well - Not being able to place the title makes it really hard to configure the nice, clean layout I was trying to achieve. Unfortunately, other than trying out the (now old) title module, I'm not savvy enough to figure out a solution myself. I had no problem placing the titles in Drupal 7. Please keep this out there - it's very important to site design.

A workaround might be if there were some way to at least grab a copy of the title text as it would otherwise be displayed at the top of the content (if block titles were made active -- the default -- in the content area). At least then, a "title" could be formatted and placed wherever a designer wished to place it on the page. Strictly keeping it at the top simply kills that option.

I don't suppose this could be accomplished thorough a template file? I can't even find a working reference to it from the available tokens.

I tried the page title module, but could not figure out how to make it work, and was reluctant to use it, considering that the release is almost a year old. I'm hoping there could be an upcoming Drupal release that might make that module scenario a big headache down the road.

Sorry for the long post on this. Would love any tips, esp. any not requiring me to be a top-level developer, which I am not.

@muranod There a few workarounds.

The most straightforward is using Display Suite with its built-in Display Suite Extras module. This will allow you to move, hide, and conditionally set the title. Some people consider DS to be "heavy" in its performance or codebase implications, but if you're looking for ease of use, that should work pretty much out of the box.

A second option is Auto Entity Label, which allows you to set the official title based on the contents of another field (which can further be manipulated or combined with other fields). In your case, you would only display the "fake" title field to end-users (thus allowing you to place it anywhere) but the nodes would still have the correct "real" title. Unfortunately, that module is still pretty unstable for D8.

A third option is just setting up another field to use as your title, and hide the "real" title on all pages through display settings. You'd then set the "real" title to something automatic, and using form alters or CSS hide it in the node edit form. Page Title module -- which controls the title of the page in the browser (and for SEO), not the Drupal title at the top of the page -- would be helpful in that case because you could use your alternate field as a token for the Page Title so that all your search engine entries are titled with what you actually want them to be. This is going to be kind of hacky, but when Auto Entity Label is ready at some point in the future it could be pretty easily repurposed into that and then be stable.

Finally, you could do most of what you need with Rules. That would take some coding for sure, but you might be able to find some recipes out there, or alternatively hire someone for that discrete task. (Though you could also hire someone to work on getting Title module going.)

Hope that helps.

(All of the above workarounds don't negate the fact that Title is a very useful, lightweight module for accomplishing something well, and I do hope work continues to get it going on D8.)

@rootwork Thanks a whole lot for the long and detailed answer. That gives me a lot to look at. I did use Display Suite in D7 and was very happy with it, but I could not find the ability to move around the title field with it in D8. Maybe I missed that and I'll have another look. It's still installed on my Dev site. Thanks again! It's been a ton of work with weird issues (even down to PHP collation problems) moving to Drupal 8, but overall, it seems brilliantly laid out to accomplish almost anything.

@rootwork I think I got it! I went through your suggestions and then back to Display Suite.

Didn't realize that I had to choose a custom Display Suite layout before the TITLE would show up as a configurable display field. (Found that by a closer reading of the page with the DS LAYOUTS MODULE.)

After setting that up, I unchecked the "Show title" option on the main content area block, but the content title kept showing twice. Turned out to be once from the PAGE TITLE BLOCK and once from Display Suite. (This is a little confusing & don't remember it working this way in Drupal 7.)

I moved the PAGE TITLE block out of the content area on the block management page and the double title was gone. Everything now looks as I wanted.

Thanks again for your suggestions.

I was also surprised to see that this wasn't fixed in Drupal 8 (8.2). It seems I have to install Display Suite just for this ...

The module Exclude Node Title will do the job. Recommended to add in core.

The module Exclude Node Title will do the job.

nope

Adding screen-shots. To hide title, this module is enough for all use cases.

Exclude Node Title only works on nodes. That's a long way frpm "all use cases".

all use cases in the sense, all use cases to hide title, which was the most useful requirement in case of title field. Other fields types may have many other use cases in manage display.

all use cases in the sense, all use cases to hide title, which was the most useful requirement in case of title field.

Have a look at the usage statistics of Exclude Node Title. January 29, 2017: 1,139 reported installs for D8. So yes, there is a use case, but it doesn't match and wouldn't replace the required use case of this issue. If you think the Exclude Node Title module should be moved to core, feel free to create a new issue for this.
Let's keep the focus on the topic of this issue, please (which is, managing the title as a field in the managing display section).

@deepak_zyxware this issue is not only about hiding the title field, it's also about positioning the title field, which "Exclude Node Title" will not do.

I'm creating a view based on content teasers, no way to hide the title of each content piece?
Not the first time I run into this issue.
This should be basic functionality, can't believe this is not possible without having to install extra modules.

You have to select fields instead of creating view with teaser view mode.

With the help of #36 and #38, I solved my issue.

I had to use the Display Suite module and apply a display suite layout. Only then the title appears in "Manage Display".

I'm completely new to drupal and i've had my issues hiding the label (was forced to use the "exclude node title" module) and now this.
It would be nice if it was a core feature to have the ability to manage display for a node title.

Here's my dream for core:

1. Allow multiple "Main page content" blocks in blocks layout.
2. On a given content type's "Manage display" page, allow site-builder to specify multiple "Main page content" blocks for a given display mode for that content type. These various "Main page content" blocks could be reused from content type to content type. Fields could be dragged into any "Main page content" block.
3. Those "Main page content" blocks could be placed into any region on the blocks layout page.
4. Now that any field could be placed in any block in any region, there would be no reason for the page title to be an exception to normal field handling! The node title would act as any other field. If the site-builder wanted to, he could drag it into a title block to match Drupal core's current behavior. Or he could mix it into the other fields on the node.

These two "simple" changes would fix a large part of my site-building frustrations from the past 2.5 years of learning Drupal!

• Problem 1: Many designers these days are calling for many edge-to-edge regions, but Drupal throws every field into one block. I'm constantly building elaborate work arounds, such as using contextually filtered views blocks to put fields into different regions while managing content from one edit tab.
• Problem 2: Most displays of content besides the main page view call for the title after some other field, such as a thumbnail. Currently, I usually pull individual fields into my view, seriously undermining the value Drupal 8's new Display modes and cutting down on the modularity of my components.

If I could bring two things into the Drupal ecosystem, those would be the things.

@Adrian83: For your problem 1, I've had success using the Field As Block module in Drupal 8, you might check that out as an alternative to having to create views and things. https://www.drupal.org/project/fieldblock

@jwilson3: Thanks for the recommendation. I am playing with Display Suite on my current project, and I must say that it goes a long way to resolving most of my frustrations. Adding the fieldblock module to the mix would allow me to put fields into any Drupal region.

I tried the fieldblock module; it is still suffering from this bug. I'll keep it in mind for the future, but for now I'll probably just create a contextually-filtered views block. I still think that if the two points in #51 could be elegantly solved in core, many people could build their sites without any extra modules or heavy workarounds.

In the last project we played with ctools's new experimental blocks module which exposes all the fields of the chosen entity types as blocks. That functionality is probably intended to be used with panels, but I found the core block placement screen cluttered and hard to use. Since the module was causing errors (if I remember right) and is marked experimental, I decided it wasn't ready to be used on a production site.

Anyway, this may be the wrong place for this discussion. Does anyone know where is the best place to pursue the topic of multiple content blocks?

@Adrian83 For the best flexibility it is effective to use ctools to make a block to show the view mode that represents the fields in a region, and then assign that block to the region. (so you divide your node into a view mode for fields in the main body region and another with fields for a hero region, for example). This is pretty solid as far as I can tell, it did not glitch out on me at any point.

I would also like this to be resolved and I don't think titles should have been hardcoded in the default templates in 8.x. In 9.x every field should be managed the same on Manage display, simply as display suite does it now.

@HongPong: Your technique sounds promising! I believe I followed everything except "use ctools to make a block to show the view mode that represents the fields in a region." Does CTools have a UI for creating blocks of a content type's fields? Or is this done in code? Is this part of the experimental "Chaos tools blocks" module?

@adrian83 yes i don't mean to get offtopic here, but it is a workaround to the problem of this issue. Create separate region if needed (ie hero or thumbnails). You should enable Chaos Tools and display suite. (Actually did not need Chaos Tools Blocks). (customize a view mode you'd like in a block with display suite: manage display per content type). Structure: Block layout: Place Block in preferred region. Add "Entity view (Content)" block. On Block Configuration, select which view mode should give you its set of fields to display.

There ought to be a name for this technique. The thing is that 'view modes' are not a very obvious name to describe what's going on or what you ought to do with them. This way you are doing everything via ds and ctools and don't need to code anything.

@HongPong Just tried your recommendation today. Of all the workarounds I've used, this is my favorite!

Really, the only requirement for this technique of showing a content type's fields in various regions is Chaos Tools to provide the "Entity view (Content)" blocks. All the view mode stuff can be done in core. However, it's almost guaranteed that the site builder will want Display Suite or another module to hide the title on each of the "Entity view (Content)" blocks in order to avoid the page title showing up multiple times on the same page.

Now the conversation is full circle, providing some context for the value of this thread. If the title could be controlled at the field level in core, core's view modes would be way more valuable; builders would not need to install Display Suite only to gain control of the title for non-full-content displays.

I plan to make a view mode called "title" and then extend & replace the title block to use this view mode if it is enabled for a particular bundle, falling back to the standard title output if not.

I totally recognize a lot here..
- Ending up at this thread and being flabbergasted this is still a thing in D8.
- The mindbending workarounds to make the block and field systems mesh.
- Using views only to output individual fields (and I also never using Custom Display Settings, for the same perceived lack of flexibility).
- The solution proposed in #51 by Adrian83 sounds really great.

(- and don't get me started on the lack of auto-update).

But in general I must say Drupal 8 is a leap forward.

@groovedork Yes, D8 is a great leap forward. And one of the greatest things is that we're able to add new features every 6 months! We can polish the rough spots without waiting for D9.

With that in mind, I recently posted some mockups in the "Drupal core ideas" issue queue, but that issue has not yet gained any momentum. You are welcome to cast your vote: https://www.drupal.org/node/2879231

@Adrian83 You probably are already aware of this, but just in case, 8.3 core added (quoted from the changelog):

"Field Layout module (experimental) which provides the ability for site builders to rearrange fields on content types, block types, etc. into new regions, for both the form and display, on the same forms provided by the normal field user interface."

I believe this addresses your Problem 1 (:

@mabdullah2010 Thank you for pointing that out. Please chime in on the discussion over at 2879231 since it feels like I've hijacked the subject of this issue.

Summary of the issue: Over in that issue, Example 1 mentions the field layout module with a few shortcomings. In short, the new field layout module is a subgrouping system within a block within a region. Blocks are placed at the region level, which means that at this point, global blocks and views blocks can be placed before or after the node's fields, but not in between. That issue lists some work arounds and provides a mockup for a cleaner solution in core. Issue 2878685 suggests another solution to this problem space.

You can also use EVA module to add node title to "manage display".

Hoping that it will be useful to some, I just released https://www.drupal.org/project/pseudo_title to tackle this problem.
Please let me know if you have any feedback and feel free to submit patches.

I use the following patch to fix this issue. It set the Title field as configurable and ensure that it is not removed from the fields list by the node module preprocess function.

Welcome Eric, thanks for your first patch on drupal.org!

You need to set the issue status to "needs review", which makes the test bots wake up. I'll do that now.

I came here after I saw #2918604: Title field not rendered with "Default" view mode was filed as a fix for this issue that hadn't yet been committed.

I've been wondering about how to do this in D8 along the lines introduced by @ericmorand. The fix itself seems simple - but the real challenge is considering backwards compatibility and minimising disruption to existing sites.

There's a whole zoo of possibilities that have to be considered. We need to identify the difficult edge cases for BC.

The Challenge

In node entity's baseFieldDefinitions ->setDisplayConfigurable('view', TRUE) is not present

In template_preprocess_node we have:

 $variables['label'] = $variables['elements']['title'];
  unset($variables['elements']['title']);
  // The 'page' variable is set to TRUE in two occasions:
  //   - The view mode is 'full' and we are on the 'node.view' route.
  //   - The node is in preview and view mode is either 'full' or 'default'.
  $variables['page'] = ($variables['view_mode'] == 'full' && (node_is_page($node)) 
|| (isset($node->in_preview) && in_array($node->preview_view_mode, ['full', 'default'])));

function node_is_page(NodeInterface $node) {
  $route_match = \Drupal::routeMatch();
  if ($route_match->getRouteName() == 'entity.node.canonical') {
    $page_node = $route_match->getParameter('node');
  }
  return (!empty($page_node) ? $page_node->id() == $node->id() : FALSE);
}

In node.html.twig we have:

  {{ title_prefix }}
  {% if not page %}
    <h2{{ title_attributes }}>
      <a href="{{ url }}" rel="bookmark">{{ label }}</a>
    </h2>
  {% endif %}
  {{ title_suffix }}

Node templates are expecting $page to be true when viewing a node in its 'full' display node on its canonical route.
Node templates are not expecting the title to be in array of fields, especially when $page is false.

The outline of a possible solution

1. Set DisplayConfigurable to true, but disabled by default.
This seems fully BC, it can't hurt.
What developers gain: nothing unless they modify the preprocess.

2. Don't remove the title in the preprocess
Take out the line unset($variables['elements']['title']);.
This breaks BC only for someone who has added the title field into the fields to be displayed prior to the preprocess, but didn't actually want to display it. Seems like a completely bizarre edge case we can ignore?
What developers gain: Ability to display the title, but as a duplicate of the normal heading in many circumstances, unless they modify the preprocess or the template.

Stopping here is safe, but leaves a puzzling out-of-the-box experience for site builders. I see 2 options to rectify it:

3 A: Set $page true if title is present in the list of fields to be displayed.
Setting $page to false causes the node template to insert a title heading, so set to true if the title will be displayed as part of the content, in order to bypass this template behaviour. This could produce unexpected results depending on how templates were being used.

3 B: Supplement $page with a new $no_title variable
In the preprocess have $variables['has_title'] = TRUE if the title is in the list of configured fields, else false.
In the template replace {% if not page %} with {% if (has_title is not defined || not has_title) && not page %}.
This seems to fully preserve BC.

What developers gain from either: fully configurable page titles, without duplicated titles even without using custom preprocess and templates, with almost perfect BC if you do use custom preprocess or template.

What doesn't work with B, but A might protect you from, is that if you have a custom template, and a sitebuilder enables the newly configurable title, then you can get a duplicate title displayed.

4 Title prefix/suffix
What I haven't considered is {{ title_prefix }} and how to handle that. Possibly it needs to be moved into the node--title.html.twig, possibly with a new preprocess argument controlling it.

So what have I overlooked?

@jonathanshaw I'm not enough of a PHP coder to give you feedback on the technicalities. However, would a more comprehensive approach such as 2879231 provide a clean backward-compatibility option?

No, as far as I can see #2879231: Allow Multiple "Main page content" blocks from "Manage Display" Screen does not solve the present issue. It doesn't allow you to display the title amidst other fields. In fact, this issue blocks satisfactory use of multiple main content blocks. Just having more than one doesn't stop it being frustrating that the placing of the title within each content block can't be controlled.

@jonathanshaw I agree with you that this issue is a blocker for the issue I referenced. My point was that the issue I referenced would be one way to allow a site-builder to work with the title either as its own block or as a field amidst other fields. In that way the title handling would be both backwards compatible and user-friendly.

You're right, if you were on the canonical route you could use a set of 2 different content blocks (the first with the 'full' view mode and the second with some other), in order to display fields, title, fields.

Leaving aside how much of an non-obvious sitebuilding hack that is, it still doesn't help when the node is rendered outside of the canonical route e.g. in an entity reference field or in a view.

Yep! Sorry for derailing your initial question in #71. Thank you for tackling the title frustration.

@jonathanshaw Nice thinking in #71. Please bear with me for a long post - there are lots of details to cover.

Answers

My responses below are based on testing out the existing code in the D8 dev title module (it doesn't fully work but it's quite close).

1) With this alone I think it is a poor UX (user-experience) - there is a UI element to manage title display but it doesn't have much effect.

Also I think there might be a bigger problem. If the title field is set to disabled, then I suspect that $variables['elements']['title'] will no longer be set, giving warnings and no title display at all.

Instead I think that the first step should be to call setDisplayOptions to match what you get in Core already: no label display, and a new "Title Formatter" that by default outputs <h2><a>.

This alone is no good, we have to keep fixing.

2) Stopping here is still poor UX - there will be 2 titles printed. That's no good, we have to keep fixing.

2.1) Extra step: template_preprocess_node must handle that title might be absent (if title hidden) giving warnings. If so probably have to set $variables['label'] = '';. Up until now label cannot be blank as title is required, so I guess it is possible that a template could work badly with a blank label; however I can't readily imagine such a case.

3A) Feels like a good approach for the majority. I agree it could cause problems if a template has extra logic based around the page variable. At this point it seems like a OK UX, but there are still some problems, see 5).

3B) The problem with this is that we can fix the Core templates, but many contrib modules and sites will override the template. Requiring those all to change is not good for BC.

4) I think you have outlined the right approach. I think that the label_display variable will be populated automatically without any new code needed for that (and it is already listed in the "available variables" comment in the template). Fix the core templates to obey this field. Same as 3B there is still the matter of custom/contrib tempaltes, but it's much less severe here: I estimate that it's less common to override this template, and also less common to want the label displayed for title.

5) One more complication is that Core uses displays the title in a block if the node is a page. After all the changes so far, that will still happen - which might be just perfect for many users who only want to control teaser title display. However anyone who tries to change manage display of the full display mode will discover the setting has no effect, which is bad UX.

The cause is that \Drupal\Core\Entity\Controller\EntityViewController::buildTitle builds a page title, which sets #printed to TRUE, and then Drupal won't display the field again. I propose that the fix is

    $variables['content']['title']['#page'] = $variables['content']['title']['#printed'];
    $variables['content']['title']['#printed'] = FALSE;

Then enhance the "Title Formatter" to present the user with a setting to control the behaviour if #page is TRUE, with two options: hide or show with alternate markup, defaulting to
and no link.

NB The site admin still has to manually configure block settings for the title block to hide it for all content types where the second option is chosen (unless someone can see a clever way to do it automatically).

Questions

Key question is whether it makes sense to add all of that to core and I'm not sure it does.

1. It's difficult/impossible: I am not sure we can make it perfect UX and BC for all cases. The site might have all sorts of strange existing logic to handle titles, from the well established Display Suite to site-specific hooks.
2. It's not essential: I am not sure why this can't be a contrib module. Yes of course ideally it would be in Core, and if D8 had not yet shipped then it would be different. However given we are now on D8.4, a contrib module seems like a perfectly workable solution. We can aim that the module be pulled into core for D9.

However what I do think we should do in Core is fix anything that is preventing a contrib module from working. Having experimented with the title module, I propose two of the above steps:
2.1) Avoid warnings in template_preprocess_node if title is missing.
4) Enhance core field--node--title.html.twig templates to pay attention to label_display.

Both of these seem to be fully BC and safe.

The rest of the code from 1-5 can live in a simple contrib module. Hopefully I will release an initial alpha soon, plus a proposed Core patch for the two items above.

Also I think there might be a bigger problem. If the title field is set to disabled, then I suspect that $variables['elements']['title'] will no longer be set, giving warnings and no title display at all.

template_preprocess_node must handle that title might be absent (if title hidden) giving warnings. If so probably have to set $variables['label'] = '';. Up until now label cannot be blank as title is required, so I guess it is possible that a template could work badly with a blank label; however I can't readily imagine such a case.

Good points. Fix is easy:

  $variables['label'] = isset($variables['elements']['title']) ? $variables['elements']['title'] : $variables['node']->getTitle();

I think $variables['label'] = ''; is unacceptable as existing custom templates will be relying on $variables'label'] being the node title.

call setDisplayOptions to match what you get in Core already: no label display, and a new "Title Formatter" that by default outputs

.

I agree a title formatter seems desirable, but I'm not clear that it is a requirement of a minimum viable core fix here. Maybe a custom title template would work OK. Could it be a follow-up?

5) One more complication is that Core uses displays the title in a block if the node is a page. After all the changes so far, that will still happen - which might be just perfect for many users who only want to control teaser title display. However anyone who tries to change manage display of the full display mode will discover the setting has no effect, which is bad UX.

The cause is that \Drupal\Core\Entity\Controller\EntityViewController::buildTitle builds a page title, which sets #printed to TRUE, and then Drupal won't display the field again.

A title formatter would be a good place to put logic that makes it configurable whether a title can be printed a second time even if it is already in the title block.

But I suggest this should be a follow up issue. Presumably this problem already exists for all entities already, not just nodes, so is reckoned to be acceptable SBX. It's not introduced by fixes we make here.

It's difficult/impossible: I am not sure we can make it perfect UX and BC for all cases. The site might have all sorts of strange existing logic to handle titles, from the well established Display Suite to site-specific hooks.
It's not essential: I am not sure why this can't be a contrib module. Yes of course ideally it would be in Core, and if D8 had not yet shipped then it would be different.

Yes, navigating the boundary of what should be core and what contrib is a central question here.

The way I see it there is a defect in core here, not merely the lack of a feature. Core is doing overly-complicated things that get in the way of customisation (it takes over title rendering rather than using the normal field rendering pattern). It's possible for custom/contrib to workaround, but it's harder than it should be. So this issue should be about removing the effect of these over-complications. Our order of priorities is:
A) Retain perfect BC for what is rendered for site visitors, regardless of customisation in place
B) Achieve good SBX (UX for sitebuilders) OOTB for new installs
C) Maintain tolerable SBX for existing heavily customised projects

A contrib module is a good solution, but this is also something that we should strive to solve in core during the 8.x cycle as much as possible within these constraints.

Let's explore the edge cases of BC and how far we can go.

3A) Feels like a good approach for the majority. I agree it could cause problems if a template has extra logic based around the page variable. At this point it seems like a OK UX, but there are still some problems, see 5).

3B) The problem with this is that we can fix the Core templates, but many contrib modules and sites will override the template. Requiring those all to change is not good for BC.

I don't think #71 3B requires existing templates to change to meet criteria A (backwards compatibility of what is rendered to visitors). It's true that in some cases the SBX will not be great if they have modified the node template, because if a sitebuilder enables the title field in manage display it may produce a duplicate or have no effect. But this is a criteria C (SBX in the presence of customisations) shortcoming that we can live with. It's also very simple for developers to fix in a preprocess hook in their theme.

Whereas #71 3A might cause a criteria A problem, changing what gets rendered for visitors. Hence it's not acceptable.

4) Enhance core field--node--title.html.twig templates to pay attention to label_display.

Do you think the label /prefix / suffix stuff can be split out into its own issue? I don't really understand it.

Another way of looking at things is that the priority here in core should be to undo the harmful effect of template_preprocess_node:

 $variables['label'] = $variables['elements']['title']
 unset($variables['elements']['title']);

which both requires the title field and disables it. This is hard for custom/contrib to work around.

The node template itself is very easy to override, template_preprocess_node is harder.

@jonathanshaw I'm afraid you have rather lost me with #78.

I feel it's important to understand the context. To me it's clearly a feature request, and what's more not one that all websites want - some sites will have custom title printing in their node.html.twig template and that needs to continue to work. Showing a double-title is something that would affect site-visitors. Many themes will ship with a modified node.html.twig and plenty of sites will change it and it's bad BC to expect them all to change.

Fortunately I can see various options that avoid BC problems and lead Drupal in stages towards a cleaner design. I am writing this from the perspective of having just coded a dev version of such a module.

1) Minimal change to allow a module to expose Manage Display of Title: "item 2.1) template_preprocess_node must handle that title might be absent. We need a Core change because otherwise there is a warning and no easy workaround. The code is fully BC. @jonathanshaw this is the first half of what you mention in #79.

Everything else has an easy workaround - in #79 you are concerned about the unset line, but it's easy to put back in hook_preprocess_node (and removing the unset is strongly not BC):
$variables['content']['title'] = $variables['label'];

2) Enhance core to allow a module to expose Manage Display of Title with no hacks and a clean design. In this option, I propose that Core would test the title field getDisplayConfigurable and if so, skip all the hacks. I currently favour this option as it seems like the best of both worlds: fully BC, but easy for module to use. @jonathanshaw I hope that this option will appeal to you too - it would be great to find a solution that we could both campaign in favour of.

With this option I would tidy up the templates in a BC way (i.e. only sites that want Manage Display of Title need to update their templates): introduce a new variable to allow hiding the title (without hacking 'page'); enhance field--node--title.html.twig to display label if configured.

3) Enhance core to allow Manage Display of Title without any modules. This builds on top of 2) and adds two things: a GUI setting to enable (would be disabled by default) and a new formatter.

I am very keen to hear views from others, especially core committers - would a patch like option 2) be acceptable for Core?

you are concerned about the unset line, but it's easy to put back in hook_preprocess_node (and removing the unset is strongly not BC):

    $variables['content']['title'] = $variables['label'];

My concern with the unset line is that it discards information. If someone set the title field to be configurable using a hook, and then a sitebuilder enabled it in some view modes but not others, that information about what is wanted by sitebuilders in different view modes is discarded by the unset in the preprocess. You code suggestion adds it back in all view modes, which may not be desired.

I propose that Core would test the title field getDisplayConfigurable and if so, skip all the hacks.
With this option I would tidy up the templates in a BC way (i.e. only sites that want Manage Display of Title need to update their templates): introduce a new variable to allow hiding the title (without hacking 'page');

Excellent. This is an improved version of #71 3B. Let's do it. I created a new implementation issue #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI as this does not completely in itself solve the present issue, though it is a key step towards doing so cleanly in core or contrib.

Patch for review in #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI

I have created a new module Manage display that runs on top of the patch in #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI

It would be great to have some comments/testing from experts. The module is not necessarily aimed to be used on a real site at the moment, it's more there as a way to evaluate the patch.

Would especially like to hear from @swentel in relation to #21

I'd love exposing it and killing that hard coded title there, a step closer for DS to die in contrib :)

Does this seems like the right direction to achieve that?

Nice job @AdamPS, it works perfectly. If anybody else wants to test it, here's a link to simplytetest.me, with the module and patch selected.

I found two minor issues: The node meta data ("Submitted by admin on Sun, 11/19/2017 - 23:53") can't be ordered, so it's stuck at the top. Also, for some reason the author name is added at the top ("admin"), but those are minor issue for now.

@ressa thanks for testing it.

If you didn't try it yet, notice that you can choose the behaviour when a node is displayed as a page: either use title block (and it won't put h2 tag in the block) OR hide it (automatically - no need to manage block settings) and put the title in the content region according to "Manage Display". Quick edit should work in both cases. If the title is hidden on "Manage Display" there will be no title at all (= "Exclude Node Title").

1) Now fixed #2923716: Allow manage display of author and date information and new alpha2 release available. Watch out, simplytetest.me seems to have a cache of alpha1 - not sure how long that will last.

It was a bit tricky because the "submitted" info comes from 2 fields not just 1. Code currently uses hook_entity_extra_field_info - I would welcome any better ideas.

2) Can workaround by visiting /admin/config/people/accounts/display/compact and setting "Name" to disabled. I raised #2924879: Set default config on enable, remove config on disable.

Thanks @AdamPS, that fixed the issues. Yes, I did notice the Hide block and use format option. It's pretty cool that you don't have to deal with the blocks section at all, but that everything can be configured from the content type display page!

A minor issue: For some reason, the submitted info is wrapped in footer-tags.

I attach my make-file for convenience, simplytest.me still seems to be caching the alpha1-version ...

A minor issue: For some reason, the submitted info is wrapped in footer-tags.

@ressa That seems odd to me too, but it's a direct copy of the existing node.html.twig.

Tested the manage_display module with corresponding patch from 2923701. Works great, but there is some side effect on the display_submitted value in the node template: the submitted template is always rendered even though the setting is false in the node config.

I guess we have to wait for the 2923701 issue final fix before being able to use this module.

@Dakwamine Thanks for trying out the module. Might you be seeing #2941678: Cannot properly control/hide submitted info? Or if not please raise a different issue in the module queue.

I would say it's too early to use the module on a live site. The current focus is to allow people to test the patch. The patch has been changing fast, and the module has got left behind a little. I hope to have a new module version soon. As you say, the top priority is to get the core patch finalised, so please do show your support on #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI if the module would help you.

I just tested the manage_display module with corresponding patch from 2923701 and that worked great. I did not experience the display_submitted issue myself; I was able to hide it with the Manage Display module no problem.

Thanks @caspervoogt

I have updated the issue summary to make this a META issue and split out a sequence of steps for resolution.

The first step to solving this issue, #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI is now RTBC. Any follower who is a core committer or who has a connection to someone who is a core committer please help us get the commit.

Updated IS sequence of steps to match updated child issues

Awesome! +1 for all the hard work on this. And the related issue is RTBC! yay!

@jonathanshaw well spotted. It looks like you accidentally set the parent/child the wrong way round - fixing that now.

Excellent news, #2923701 has been committed. I have created a new release of contrib module Manage Display which will work without core patches in D8.7.

Please follow/review/help for the next stages - see IS.

IS:

If we want to deprecate the old hard-coded display in D9, then the alternative must be ready in D8 - which seems to mean October 14, 2019.

We would have to move fast to hit that. There is time to write the code, but the review/commit cycle for the first issue was very long. On the plus side we now have an established strategy so it should be quicker. It would be great if the core committers could help streamline these issues.

Great news. Thanks for everyone's work on this.

Great news @AdamPS as I think this is VERY important for more flexibility in Drupal 9 and a great chance to remove the hard coded things in that step. As #2923701 is FIXED in 8.7.x we should proceed with this and don't miss the deadline for D9.

Wouldn't it make sene to use https://www.drupal.org/project/manage_display as playground, for individual issues and once it is stable, create a core patch from that instead of blowing up the discussion here?

@Anybody The key next step is fixing the other core issues described in part A of the issue summary. Some of them are in a needs work state, and contributions would be very welcome.

For part B, then yes the Manage Display module can be a "playground". Already it works in a simple way (no config options). I feel that it's difficult to do much more until the issues in part A are fixed.

We are getting close to completing part A. The 3 remaining issues are now all RTBC.

1. #2993642: Mechanism to disable preprocessing of base fields in taxonomy and aggregator entity types so they can be configured via the field UI
2. #2993647: Correctly determine when to display fields as inline
3. #2941208: Title formatting broken due to flawed EntityViewController->buildTitle fix the interaction with the title block.

The first one is almost identical to the issue that was committed in 8.7. The second + third have been RTBC for a while and had reviews from key experts.

It will be great if we can get these all committed to 8.8.0. If any one following is a core committer or co-worker of one, then we would all be very grateful if you can take a look, thanks.

#2993642: Mechanism to disable preprocessing of base fields in taxonomy and aggregator entity types so they can be configured via the field UI is now Fixed.

Added a new child issue #3090187: Mechanism to disable preprocessing of base fields in comment entity type so they can be configured via the field UI.

I would love to hear some thoughts on this approach the other way around, but I am not sure if this is a duplicate of a discussion I missed.

https://www.drupal.org/project/manage_display

#2993647: Correctly determine when to display fields as inline commited and only 2 issues left in A

Great news: phase A is now complete. Many thanks to all the reviewers and especially the core committers for their support. This allows for a stable release of Manage Display module without any "hacks" for Drupal Core >= 9.4.

During phase B we will aim to add the function of Manage Display into Core.

I've been considering the way forward here, and the deprecation strategy.

The hardest challenge is to handle enabling isDisplayConfigurable(TRUE) on existing installations. There are a lot of permutations to consider:
Is isDisplayConfigurable() already set?
Is enable_base_field_custom_preprocess_skipping already set?
If isDisplayConfigurable is set, is the field configured to be visible or hidden?
Is the site using a core or custom template?

I see two ways forward:

Strategy A - the forceful way

1. In 9.4 deprecate having the base field ->isDisplayConfigurable(TRUE) without using enable_base_field_custom_preprocess_skipping. We could actually have done this whenever we introduced enable_base_field_custom_preprocess_skipping.

2. This means that from 10.0 we can trust that anyone with isDisplayConfigurable(TRUE) has templates and/or configuration setup to not depend on the custom base field preprocessing. In 10.0 we can skip preprocessing if EITHER enable_base_field_custom_preprocess_skipping OR field is ->isDisplayConfigurable(TRUE).

3. Once we have #3033301: Add formatters and other mechanisms as alternative to base fields directly in entity templates we can at any time in 10.x:

• a. set isDisplayConfigurable(TRUE) on the base fields
• b. in an update hook configure the base field to appear in a place corresponding to where it would have been previously hardcoded to appear in the template, unless enable_base_field_custom_preprocess_skipping is set in which case we assume it is already configured as desired.
• c. Remove the custom preprocessing code.
• d. remove the custom template code
• e. trigger a deprecation error if enable_base_field_custom_preprocess_skipping is set, saying it is now redundant.

Strategy B - the safer way

1. In 9.4 deprecate having the base field ->isDisplayConfigurable(TRUE) without using enable_base_field_custom_preprocess_skipping. We could actually have done this whenever we introduced enable_base_field_custom_preprocess_skipping.

2. In 10.x

• a. set isDisplayConfigurable(TRUE) on the base fields
• b. skip preprocessing if EITHER enable_base_field_custom_preprocess_skipping is set OR (field is ->isDisplayConfigurable(TRUE) AND field is a child element (i.e. has been explicitly configured to be visible).

4. Once we have #3033301: Add formatters and other mechanisms as alternative to base fields directly in entity templates we can at any time in 10.x add a twig deprecated tag to templates if the custom preprocess variable is set and used in the template, instructing sitebuilders to explicitly configure the field to be visible instead of relying on the template's use of the custom preprocess.

5. In 11.0

• a. remove the custom preprocessing code
• c. remove the custom template code
• b. trigger a deprecation error if enable_base_field_custom_preprocess_skipping is set, saying it is now redundant.

Either way we may cause a hard BC break for some cases of custom templates relying on the preprocess variables; it's just unavoidable.

I believe the safer Strategy B is much preferable to the forceful strategy A. The problem with A is the forceful configuring of fields to be visible by an update hook requires us to wait on developing a 100% perfect drop-in reimplementation of the existing experience in #3033301: Add formatters and other mechanisms as alternative to base fields directly in entity templates. This will be he hard to, and would force us to perpetuate legacy aspects of the current base field display. Allowing sitebuilders to gradually opt-in and configure to their tastes is both less risky and allows us to modernise more freely and gradually.

#118 B looks like a good plan to me!

I like the progress. And I agree; #118 Strategy B looks safe and the way to go.

I have thought about the deprecation issue in great detail, and based on that I created the various issues and outlined how they link together in the issue summary here.

@jonathanshaw Closed #3036862: Expose Title and other base fields in Manage Display in Drupal Core saying in effect that it is "too slow". Well it takes the same number of major releases as any other suggestion. True it does require users to opt in, introducing an option that would be deprecated. However I have yet to see any other proposal that works and is compatible with the Core BC rules as I understand them.

I think that people potentially don't fully understand the complexity of the changes needed here. I am maintainer/developer or the Manage Display module, which makes the configurable display work correctly. The file manage_display.module contains 170 lines of code that are needed to do this. The proposed GUI option would activate all of these changes, on an opt in basis.

I believe both the strategies in #118 are far from working. Strategy B is favoured so I'll respond to that.

• Point 2a suggests to set isDisplayConfigurable(TRUE). This would turn off the custom preprocessing, however it would not enable anything else to replace it. The title would show as plain text rather than a heading and link. The submitted information would show as two separate fields rather than the current "Submitted by UUU on DDD". The fields would appear in unpredictable places unrelated to where they appear currently in template files and probably would all show a field label. Fields that were previously hidden would suddenly become visible. Any site that has not updated their templates as recommended in recent change records (which is entirely legitimate) would suffer further problems. So suddenly everyone's sites are totally broken.
• Point 2b is also incorrect although less disastrous. Any attempt to modify the logic for custom preprocessing would be a non-BC change.

Either way we may cause a hard BC break for some cases of custom templates relying on the preprocess variables; it's just unavoidable.

As far as I know hard-BC breaks are not currently allowed. It's strange to say it's unavoidable when I described a way to avoid it and I've yet to see any reasoning that says why it won't work.

In any case, the deprecation question is quite far off as first we need #3033301: Add formatters and other mechanisms as alternative to base fields directly in entity templates. We can't deprecate anything until we have a workable alternative.

As far as I know hard-BC breaks are not currently allowed.

This is true for things we provide bc for, however we don't provide bc for render arrays, or non-classy/stable templates, see https://www.drupal.org/about/core/policies/core-change-policies/drupal-8...

This doesn't mean we can just nuke $submitted in a minor release, but it does mean we can expose replacements straight away, and find some kind of way to deprecate the old template variables with the intention of removing them. Triggering deprecations, phpstan etc. are all options.

Thanks @catch.

I have updated the issue summary of #3036862: Expose Title and other base fields in Manage Display in Drupal Core. Hopefully it's now clearer that it covers turning on isDisplayConfigurable(TRUE) plus all the many related changes to base field definitions. If anyone wishes to continue the discussion in comments #118-121 then I propose that #3036862 is the place to do it.

I also updated the issue title so it no longer insists that there would be a GUI option. I still believe that's the best/necessary approach otherwise the transition in a minor release will be abrupt, irreversible and likely not fully BC. However I'm open to explore other possibilities if they really can work without breaking sites.

I have found one more little problem for phase A: #3220754: Book printer-friendly version should respect configurable title display. I have created a patch with tests ready for review. If anyone can help by reviewing that would be useful thanks.

As Title is not a field, it therefore isn't exposed in Schema for the Field settings / View mode endpoints of jsonapi.
/jsonapi/field_config/field_config

It would be great if exposing it here could be included in this work.

No, that has nothing to do with that and I can tell you no that will almost certainly never change. json_api doesn't deal with field definitions, it deals with field_config entities.

Tagging this with Field UX - while it's not a generic issue with the field UI, it is extremely confusing that you can control some things with field UI and some not, forces people back into templates and or looking around in content types settings forms or theme settings etc.

Take a look at https://www.drupal.org/project/base_field_override_ui

As @AdamPS wrote in #3220754: Book printer-friendly version should respect configurable title display, that's no blocker.

So the (blocking) obstacles are now all solved and we can proceed with the further steps! Yay! :)

I added two issues to the list of phase A. #3381877: Wrong comment display for sites configuring base field display in the UI is "needs review"

Only one blocker left #3342700: Reinstate important testing NodeDisplayConfigurableTest

Great so phase A is now complete.

I suggest that a good next step would be #3470497: Add a tag select list in string Formatter. The code already exists in Manage Display module, so it just needs someone to write a test. I've moved on to other things now so hopefully some others have enthusiasm for the next phase.

I added two new issues to part A and any comments/work to help solving these would be appreciated.

These are not blockers so we can continue with part B in the meantime.

This would have been a great feature to have in Drupal CMS, but hopefully in 2025 it can reach completion?

By the way, the heading is "A Fix obstacles to manage display in contrib" which I understand as "semi-blockers", but they seem to not be?

@adamps:

I added two new issues to part A and any comments/work to help solving these would be appreciated.

These are not blockers so we can continue with part B in the meantime.

Perhaps move these two issues below "C" under a "Nice to have" header to prevent users skimming the Issue Summary from concluding "Oh, A is still not done ..." and don't look at issues under "B", thereby stalling progress?