Problem/Motivation

We have many template files that start with logic that, if fails, will prevent anything from being printed at all. It would be smarter if we could prevent these template files from being rendered at all when not necessary.

For example, theme_comment_post_forbidden turns into the following twig file:

{% if logged_out and can_post_comments %}
  {% if user_register %}
    {% set args = {'@login': user_login_url, '@register': user_register_url} %}
    {{ '<a href="@login">Log in</a> or <a href="@register">register</a> to post comments' | t(args) }}
  {% else %}
    {% set args = {'@login': user_login_url} %}
    {{ '<a href="@login">Log in</a> to post comments' | t(args) }}
  {% endif %}
{% endif %}

Proposed resolution

We should think about whether we should find a way to allow Twig/the theme system to skip the rendering of a template when these conditions are not met.

Some possible candidates:

(Click View source to see the template code)

Remaining tasks

TBD

User interface changes

none.

API changes

TBD

#1706612: remove 'submitted' variable in templates for ease of theme development

Comments

jenlampton’s picture

Issue summary: View changes

more words

joelpittet’s picture

Issue summary: View changes

This sounds like it may be something to consider with '#access' => FALSE on a renderable array?

Cottser’s picture

Issue summary: View changes

I think we should also keep in mind the "API" of the theme system and what developers expect when using themeable components. For example, do module developers/theme developers expect things to be handled for them or that they might have to handle some logic up front? I think right now we have a mixture, it's not consistent.

I did a quick search and added some candidates to the issue summary.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.