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

feedSymfony Blog

A Week of Symfony #1027 (August 31 – September 6, 2026)

This week, Symfony 6.4.45, 7.4.18, and 8.1.6 were released with numerous bug fixes and hardening improvements. Meanwhile, we introduced symfony lsp:check, a new command that brings Symfony-aware diagnostics to your CI pipeline, catching unknown routes, missing…

06 Sep 2026 7:46am GMT

feedDrupal.org aggregator

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

02 Sep 2026

feedSymfony Blog

Meet the Symfony Core Team at the API Platform Conference 2026!

The API Platform Conference, the international event dedicated to the API Platform framework and its ecosystem, will take place in two weeks in Lille, France, on September 17-18, 2026. Nearly 30 talks are scheduled, in both French and English, covering…

02 Sep 2026 2:30pm GMT

31 Aug 2026

feedSymfony Blog

Introducing symfony lsp:check: Symfony-Aware Diagnostics in Your CI

A Symfony application is full of strings that mean something: route names, template paths, translation keys, service ids, bundle configuration keys. To PHP, they are strings like any others. Your CI pipeline verifies types with PHPStan or Psalm, style with…

31 Aug 2026 12:03pm GMT

01 Apr 2004

feedPlanet PHP

ezSystems are classy folks

cover
Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

PHP april fools...

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

PHP Virus Attacking Web Hosts

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT