06 Sep 2026

feedDrupal.org aggregator

PreviousNext: If you're using Twig's raw filter with Drupal, you're doing it wrong

With some recent security advisories for Cross Site Scripting (XSS), it feels like an opportune time to remind those who author Twig templates for Drupal:
If you're using Twig's |raw filter, you're probably doing it wrong

by lee.rowlands /

Background

Let's cast our minds back to Drupal 7. A time before twig. We had .tpl.php templates with PHP template as the default templating engine. Every variable available in your template had to be carefully sanitized before being printed to avoid XSS.

This meant remembering to call check_plain or check_markup in preprocessing hooks on every variable.

Not surprisingly security advisories for Cross Site Scripting (XSS) were the the number one vector in Drupal contrib security advisories for Drupal 7 and below.

The release of Drupal 8 saw the adoption of Twig as the default templating engine. With auto-escaping by default, Twig promised to provide enhanced security against XSS vectors. No more needing to remember to call check_plain or check_markup - any variable available to Twig was escaped on output!

Using raw bypasses Twig's protection

Which brings us to using the |raw filter. When you use it you're saying to Twig - actually, don't auto-escape this variable, I know better.

But there are very few cases where this is the correct approach.

And in reaching for |raw you're most likely opening an XSS vector.

What to use instead

If you're looking at a template and you're finding that a variable is being double-escaped. E.g. instead of Mathematics & Data Science you're seeing Mathematics & Data Science you might be tempted to reach for raw to fix it.

Instead you need to examine where the value is coming from.

If you're using Drupal's field formatters, you're unlikely to get into this scenario. The most likely cause is you're accessing raw field values.

E.g. something like $node->field_body->value in either a preprocessing hook or some ungainly Twig expression {{ node.field_body[0].value }}.

Check the type of the field. If its in the Text family, e.g. Text, Text (long), Text (long, with summary). You should instead be using the processed property - $node->field_body->processed. This has already been sanitized and is flagged as safe to Twig. Anything flagged as safe bypasses auto-escaping.

If you're doing something custom, like in a configuration form or similar, lean on the TextFormat form element - '#type' => 'text_format'. This gives you a value and format pair. You can use this with the '#type' => 'processed_text'render element and again, the returned value is already marked as safe.

Failing that, if you want a limited set of HTML tags to be allowed and don't have a filter format to use with the ProcessedText element, you can use a #markup render array. E.g instead of printing a string, use ['#markup' => $the_string] - this will go via Xss::filter with the admin tags list. It will allow through some tags, but will strip out those that can lead to XSS.

So before you reach for |raw

So in summary. If you find yourself reaching for the |raw filter, stop. Instead lean on ProcessedText and pass a format, either one you define or one that the users chooses. Or failing that, use ['#markup' => ...].

Perhaps for some homework, go and check your themes and make sure you don't have any use of raw. Remember to follow the procedure for reporting a security issue if you find anything in a theme with security team support.

06 Sep 2026 11:00pm GMT

Berliners blog: Rebuilding a data-driven Drupal site: Page templates with Layout Builder

Rebuilding a data-driven Drupal site: Page templates with Layout Builder

In the previous post in this series, I described how we migrated existing page elements from Panels to Layout Builder.

Pages on this site are assembled from configurable page elements implemented as block plugins. These elements display data managed by an external system. Drupal stores their arrangement and configuration, but not the underlying data.

berliner

06 Sep 2026 7:59pm GMT

Gspikes: Drupal 11 Adoption Tracker: The Curve, the Cliff, and 260,000 Sites

Drupal 11 is on 36% of reporting Drupal sites - and climbing at roughly half the speed Drupal 10 managed at the same age. On 9 December 2026 Drupal 10 reaches end of life, and the share of the Drupal web running unsupported code nearly triples overnight. The live numbers, the method, and what the curve actually says. Updated quarterly.

06 Sep 2026 4:01am GMT