• Strings such as "On This Page" are ok.
• Blocks of content such as the public reuse or commenting block are not. This is due to the fact that:
  • Content owners "own" that content and should be able to update it when the need arises.
  • Embedding it in templates means that we cannot have different blocks for different sites.

This should always be done through the translation systems. {% trans %}Your Text{% endtrans %} or t()

Preprocessors should be the last line of defense for manipulating content structures. For content types that we create, we have alternate ways of manipulating the content object. Such alternatives could be:

• hook_ENTITY_TYPE_view() or hook_ENTITY_TYPE_view_alter()
• Field Formatters
• Pseudofields + formatter

Additionally, since we are working on multiple themes, it is extremely important to think about how a preprocessor maps to content types that may not be used in a theme. It becomes more complex to manage. When the alterations are with the content types, it is:

• Available to any theme that could use that content type
• Available to any third party theme developer.

BAD

{% if content.field_to_display[0] %}
   {{content.field_to_display}}
{% endif %}

GOOD

{{content.field_to_display}}

GOOD

{% if content.field_to_display[0] %}
  <div class="alignRight">{{content.field_to_display}}</div>
{% endif %}

This example adds markup around the field content, so you should check for a value before outputting unnecessary markup.

BAD

<a href="https://www.google.com/search?q={{ content.field_search_string|escape|striptags('<!-- -->')|trim}}">{{ content.field_search_button }}</a>

This example is rendering a string field, escaping bad characters†, stripping twig hints and removing white space.

OK (Native Twig)

<a href="https://www.google.com/search?q={{ content.field_search_string[0] }}">{{ content.field_search_button }}</a>

BETTER (Twig Field Value) We have the Twig Field Value template and you can get the value of a field by doing the following:

<a href="https://www.google.com/search?q={{ content.field_search_string | field_value }}">{{ content.field_search_button }}</a>

† NOTE: In the above example, escape may be a good choice in order to escape special characters from the url.

BAD

{% if content.field_search_string|field_value %} 
<a href="https://www.google.com/search?q={{ content.field_search_string|field_value|escape('url')}}">Search Results</a>
{% endif %}

This example is basically doing a check that the Drupal theming would normally do inside a field template. Additionally, it clutters up the Entity template. GOOD

field--field_search_string.html.twig:
{% for item in items %}
  <a href="https://www.google.com/search?q={{ item.content|escape('url')}}">Search Results</a>
{% endfor %}

entity--bundle.html.twig:
{{ content.field_search_string }}

If you have a flag or some sort of display mode setting that dictates which fields to show, BUT does NOT render, do not add that field to the display mode. Instead in your twig template access the entity field directly. BAD

{% set style = content.field_list_item_style[0][`#markup`] %}
{% if style ... %}

GOOD

{% set style = paragraph.field_list_item_style.value %}
{% if style ... %}

Where paragraph could also be node, user, etc... Check that entity types twig documentation for the entity object name.

• Don't target entity identifiers