07 Sep 2026

feedDrupal.org aggregator

Très Bien Blog: composer drupal-patch-check

composer drupal-patch-check

A composer plugin created to make it easy for humans to upgrade their patched Drupal websites.

If you ever wanted to know if you still needed that patch after an update, or if your custom patch would still apply to the new version of the module, or if your 15 levels patch tower still applies after the update, this is the tool for you. Install the composer plugin and get started using the remote API.

theodore

07 Sep 2026 10:00am GMT

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