Field access operators

There's one thing that you'll probably need to do the most in your Twig templates: Access the fields of some Drupal entity. After all, this is what templates are all about. Rendering content that's stored in entities in different ways. And that content obviously resides in fields. So you'll probably need to access those fields a lot.

First and foremost, there are basically two different ways to access those fields. On the one hand, you might simply want to render a field. That is, you want to have the full HTML - including all the associated tags, labels etc. - exactly like defined by the field's display settings and field formatter. One the other hand, you sometimes want to have the raw value of that field. That is, without any surrounding tags, encoding or HTML. Just the pure value that's stored in the database. This second case is often used when you don't want to output a field, but use its value for comparisons etc.

$ operator (Field render operator)

With standard Drupal, you can get a field's rendered content as HTML from a Twig template with:

{{ content.field_myfield.0 }}

DrupalX introduces the new "$" operator to access the rendered HTML content of fields. The example above can now be written much shorter as:

{{ $myfield }}

As you can see, the "field_" prefix isn't necessary here due to DrupalX's field name mapping and the ".0" isn't necessary either, because of DrupalX's cardinality detection.

# operator (Field value operator)

With standard Drupal, you can get a field's raw value from a Twig template with:

{{ entity.field_name.value }}

DrupalX introduces the new "#" operator to access the raw field value. The example above can now be written much shorter as:

{{ #myfield }}

As you can see, the "field_" prefix isn't necessary here due to DrupalX's field name mapping and the ".value" suffix isn't necessary either, because of DrupalX's scalar value extraction.

$$ and ## operators (Inherited field render operator and inherited field value operator)

By simply doubling the $ or # operator, you can access inherited fields. DrupalX follows the full field hierarchy upwards until a non-empty value for this field is found. In case of a paragraph, this means DrupalX will first check all the parent paragraphs up to the entity's top-level. If a non-empty field with that name is found in any of the parent paragraphs, that value is returned. If DrupalX arrives at the entity's top-level without finding a non-empty field, it will continue searching the menu hierarchy up to the front page. We highly recommend reading the chapter about paragraph-only layouts to understand this better, if you haven't already done so. You'll also find a small example over there.

The $$ and ## operators are useful for 2 main purposes:

First, you can use those operators to easily create content like sidebars, footer etc. that is only managed on the home page or a central category landing page and then automatically inherited to all other child pages - at least until that content is, in turn, overriden by some different content. This feature can therefore replace Drupal's "blocks" feature.  Second, you can use those operators to create options that automatically take effect for all child pages - removing the need for content editors to set them for each and every single page. In the following example, there's a field "category" (e.g. a drop-down list with some categories like "business", "customers", "internal") and selecting a value there will modify all child pages at once:

{%
if ##category=="business";
  set color="A00000";
endif;
%}

$$$ and ### operators (Aggregated field render operator and aggregated field value operator)

Now, taking the previous section one step further, by tripling those operators, you will get an aggregation of all inherited fields i.e. DrupalX follows the full field hierarchy upwards and collects all non-empty values it finds.

You can use this, for example, to create inherited content - e.g.sidebar elements - which isn't completely replaced if similar content is defined on child pages but merged together. A child page will contain all sidebar boxes that have been defined up to the front page of your site.

Another way you can use this, is by combining it with Twig's standard "in" operator to find out whether a certain value has been set in any higher hierarchy level: