Twig has this awesome idea of template inheritance that will prevent us from duplicating markup in two templates like we do now. We will need to ship Drupal 8 core with examples of how to use inheritance, and this issue will serve as a meta issue where we can track (and evaluate) where and how it should be used.

This issue will help is decide on some standards we can document about when to inherit!

Places we should use twig template inheritance

Related

#1923992: Rename 'block' to 'codeblock' in Twig for Drupal - re template inheritance

Comments

jenlampton’s picture

Project: » Drupal core
Issue summary: View changes

added link to related issue

jenlampton’s picture

Issue summary: View changes

br

jenlampton’s picture

Project: Drupal core »

I found one place where this could be useful in core: comment-wrapper.html.twig

There is an if statement in the template to see if forum module is involved. Instead, we should put a twig block in here (probably also with a documentation comment?) and Forum module should provide a twig template override that demonstrates inheritance.

This is what the comment-wrapper.html.twig file looks like currently:

<section id="comments" class="{{ attributes.class }}"{{ attributes }}>

  {# TODO forum module should extend comment template to keep the code in here clean #}
  {% if comments %}
    {% if node.type != 'forum' %}
      {{ title.prefix }}
      <h2 class="title">{{ 'Comments' | t }}</h2>
      {{ title.suffix }}
    {% endif %}

    {{ comments }}

  {% endif %}

  {% if form %}
    <h2 class="title comment-form">{{ 'Add new comment' | t }}</h2>
    {{ form }}
  {% endif %}

</section>

Here's an example of what comment-wrapper.html.twig could look like with twig template inheritance:

<section id="comments" class="{{ attributes.class }}"{{ attributes }}>

  {% if comments %}
    {% codeblock title %}
      {{ title.prefix }}
      <h2 class="title">{{ 'Comments' | t }}</h2>
      {{ title.suffix }}
    {% endcodeblock %}

    {{ comments }}

  {% endif %}

  {% if form %}
    <h2 class="title comment-form">{{ 'Add new comment' | t }}</h2>
    {{ form }}
  {% endif %}

</section>

And here's an example of the corresponding forum override, comment-wrapper--forum.html.twig:

{% extends "comment-wrapper.html.twig" %}

{% codeblock title %}
  {# code block here is empty to prevent title from showing on forums #}
{% endcodeblock %}

We may need to add a theme_hook_suggestion for a comment-wrapper--forum.html.twig in order to make this work. But it seems like this is a good use case for such a thing :)

jenlampton’s picture

Also, see my proposition for renaming Twig blocks to codeblocks here: #1923992: Rename 'block' to 'codeblock' in Twig for Drupal - re template inheritance :)

jenlampton’s picture

Title: When should we use Twig template inheritance? » [meta] Use Twig template inheritance
Project: » Drupal core
Version: » 8.x-dev
Component: Documentation » theme system
Category: support » task

I'm moving this issue to the core queue so that we won't forget to add examples of template inheritance in core before d8 releases. Also converting to a meta issue so that we can track where we should be using it, so we can come back and add each instance later.

jenlampton’s picture

Issue summary: View changes

added more of why there should be no templates that are the same

c4rl’s picture

Since Drupal theming has suffered from too many APIs and too many tools, I think we need some really clear and useful examples before this gets into core. I don't think just because an Twig feature exists means that we must use it for the sake of its mere existence.

The example above in #1 isn't quite compelling enough, so I'd be interested in seeing other ideas.

I also think if D8 ships with no examples of this, that is ok since we have made other big improvements elsewhere.

c4rl’s picture

Issue summary: View changes

up

c4rl’s picture

Status: Active » Postponed

I am re-posting my comment on #1285842-13: Forum module should implement its own node and comment templates to make theming easier here since it is more applicable.

One concern I have with how Twig inheritance is proposed to work is that the original template must decide what the child template is going to potentially want to change. That is, if there's not a codeblock that is useful to you in the original, then you have to override the whole thing anyway.

So, I'm not sure this API really provides us with anything new. Traditional overriding of the template registry is something we're familiar with and provides more flexibility.

I am postponing this issue until we have more compelling rationale than simply "let's fine a potential use case for inheritance simply because inheritance exists."

steveoliver’s picture

+1 to #4 and #5.

jenlampton’s picture

Status: Postponed » Closed (works as designed)

sounds like we don't want to do this in core. closing.

jenlampton’s picture

Issue summary: View changes

link