Change block "label" so thad a title like everything else in the template file (and all other template files)

We really do not need $block->label. At the minimum we should have $block->title.

But for all of us themers and developers, we should stick to $title.

less snark

I'm all for changing label to title and getting this consistent. Updated the summary to show the current twig and some other minor changes.

At what point does it make sense to change the entity-provided "label" to the theme-friendly "title"?

@akalata Very good question, maybe worth asking in IRC #drupal-contribute to someone working on the entity system.

First contribution attempt. Apologies if way off target. Comments/advice appreciated.

Hi @simetau, thanks for your contribution!

Block UI uses Title, so this change seems rather valid to me even if it's inconsistent with the internal entity properties.

The changes overall look good to me, but we need to be careful to update all the block files that use or document label/title. I think only one might be missing but haven't looked very thoroughly:

/core/themes/classy/templates/block/block--system-menu-block.html.twig (it's documented at the top in the docblock)

Also we should update the docblock at the top of the templates to change label to title (but only for the "top level" label). This is where it might make sense to also have the documentation state that 'title' is equivalent to 'label' in internal block speak.

On a related note I'm mystified as to why block--system-menu-block.html.twig uses configuration.label instead of label. Probably needs a code comment (separate issue I'd say).

Thanks @Cottser for the feedback and patience. I have updated 'label' to 'title' in the docblock at the top of template files (stole your 'internal block speak' line - wasn't sure on the voice) along with another comment in block.module.

I'm not sure on the other references to 'label' further down in the configuration area of the docblocks.

As always, advice and feedback needed and welcome.

Needs review.

@Cottser, the template first showed up here, #1869476: Convert global menus (primary links, secondary links) into blocks. Wim's patch in #153. I didn't read through the issue though so I don't know the explanation. 'configuration' existed before that though.

Check if these also need changing:

core/modules/comment/templates/field--comment.html.twig
core/modules/system/templates/field.html.twig
core/themes/bartik/templates/field--node--field-tags.html.twig
core/themes/classy/templates/field/field--comment.html.twig
core/themes/classy/templates/field/field.html.twig

Form element seems weird too:
core/modules/system/templates/form-element.html.twig
core/themes/classy/templates/form/form-element.html.twig

We have a title_display variable?

equivalent to 'label' in internal block speak

Is there a reason why block uses label and title inconsistently? I see both being used in various places.

Thank you both. Just quickly I think this issue should only touch block templates, other templates should be handled separately IMO.

@Cottser, that's fair; considering it is in the issue title. :)

I don't know if the documentation gods would approve of the wording of the parenthetical comment. That would be my only nit.

I'm removing the other stuff from the issue summary and adding beta evaluation.

I'm not sure about this being an unfrozen change.

According to the documentation page, unfrozen changes are:

• CSS
• markup
• translatable strings
• documentation
• automated tests

This change goes beyond that, since it's also change twig template variables. I guess the proper way of going about this is add a new variable and deprecate the old. If I'm correct about this, this should be postponed to 8.1.x

@googletorp, we should be fine. We are still making occasional template variable changes, but this will have to be done before release candidate (RC1). Then it will be frozen. After that, I don't think we can push it to 8.1. It would have to go to 9.x, because we can't really make backwards compatible changes to templates.

We could push to 8.1.x by not deleting the old variable right away, but only deprecating it.

If it's general practice that template variables are OK to change, I guess this is fine. I wondered since this would break existing themes (sites) using this variable in the block template file.

Hmm, I do kinda like the idea of keeping label as a BC thing, as long as we comment it accordingly.

It isn't just an issue of the adding a new variable. We can't change the markup for the template in 8.1, which negates any reason to add another variable or change its name.

We wouldn't change the markup, that would still be the same. The only thing we would change is the name of the variable. The actual output of the variable would be the same as the old. So there wouldn't be any change, instead we would have two variables for the same thing, until the deprecated one was removed.

But like I said, if there is a practice for doing this kind of thing for beta, then this is pretty irrelevant.

We would be changing which variable is printed in the template, but the code of the templates themselves is frozen through the life of the major release.

It doesn't seem to make much sense though to live with an extra variable just for this. It's not hurting anything to leave it until it is fixed properly.

Cottser and I just did some talking on this. We'll get a committers feedback to see what we can do.

We talked to webchick and alexpott in irc. My impression is everyone agrees the whole inconsistency problem all over core with how label versus title is handled is a big problem. But, it was discovered this particular change was done on purpose. See here, #1642070: Make use of entity labels in templates.

So, if we tried to fix this we should be switching everything (title_attributes) to use label instead, unless we want to have a discussion about preferring title (which no one wants to have.) The actual breaking change of renaming the theme variable seemed to be less of a concern.

Given the amount of work it would take to switch the title usage to label (not just in block), and the even greater number of things we'd be breaking, this is unlikely to happen in 8. We should probably push this to 9.x. @Cottser do you agree, or prefer a different course?

@googletorp, thanks for the diligence.

@simetau, I want to find something else for you to work on. (maybe something that isn't 2 years old. :P ) If I find a good issue I'll leave you message in irc.

Yeah, this seems too disruptive for beta/8.0.x and would be a breaking change in 8.1.x so sadly bumping the version. We need to approach this confusion and WTF-ness from a holistic place.

Thanks all.

Let’s not jump too quickly please! We have not reached RC yet. And even beta to beta upgrades are not currently possible, unless using the head to head project.

Why can’t we have $title variables in the TWIG templates is confusing. We do not want to print the label of a field, but the value of the field. So for a node title themers will want and prefer $title.

The idea of supporting both $title and $label in the 8.0.x release is much better; it'll be easier to remove the extra $label in 8.1.x.

Can we at lease see the point of view of maintainers?

@xmacinfo, I did outline some of this reasoning in comment #25. Also, see the issue I linked where this change to have label was purposefully introduced by a consensus of core themers. Cottser and I discussed this at length with webchick and alexpott who are both core maintainers, and Cottser is one of the theme system maintainers.

You may also be confusing the issue a bit. This isn't preventing anyone from printing the value of fields. This is only about the naming of the variable that is being used. No actual functionality would have been affected.

No actual functionality would have been affected.

Agreed! But the perception is affected! :-)

I think we can do this with two variables, label being deprecated, and stable, in a minor release.

So people work on it, I'm unpostponing.

Quoting myself from #1939234: Change node "label" so that it's called a title like everything else in the template file (and all other template files) as it applies here too.

This issue has gone stale for almost 10 years.

I'm actually somewhat against this change, label is a consistent Drupalism applied to all entity types. Title is not. E.g in #1939224: Change block "label" so that it's called a title like everything else in the template file (and all other template files) blocks don't have a title, they have a block description or label.

If anything, the title_prefix/suffix/attributes should be the ones to change?

Same comment here.

To get more developers on Drupal, some "Drupalism" needs to go.

Developers are typically giving a name to the things they create.

- Name of the block
- Name of the variable
- Name of the function
- Name of the field

A label is a tag attached to an item.

So either we continue putting Drupal in a corner with its "Drupalism" or we adopt more generalized standards.

Will agree with #47 we do use label everywhere else. So are we trying to change everywhere now?

From the IS:

 {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}

We need to be consistent. Either use “Drupalism” or use standards.

Standards (or the request from the IS:

{{ title_prefix }}
  {% if title %}
    <h2{{ title_attributes }}>{{ title }}</h2>
  {% endif %}
  {{ title_suffix }}

Drupalism:

{{ label_prefix }}
  {% if label %}
    <h2{{ label_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ label_suffix }}

For consistency, we must not mix both title and label.

#47 and #49 opt to keep label. So lets make it to:

 {{ label_prefix }}
  {% if label %}
    <h2{{ label_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ label_suffix }}

The problem is that would be an extraordinary amount of work. It's not just block using those variable names, there's 56 twig templates alone with this variable in them in core. This spans blocks, comments, fields, media, nodes, search results, taxonomy terms, views, and more. The effort to deprecate title_prefix and title_suffix with BC in mind would be a huge amount of code for what IMO is very little gain.

I taught we were discussing drupalism VS standards. And so, speaking about consistency.

Based on the vast amount of work we might prefer closing this ticket as is.

Your comment (#51) is self-explanatory. It explains correctly why we won't fix this 12 years old issue.