Twig support in "Text area" fields just like "Custom text" fields

Created on 8 December 2016, almost 8 years ago
Updated 10 April 2024, 8 months ago

Problem/Motivation

The global "Text area" that can be added to footer, header or no-result areas is not meant to fully support twig. Background: https://www.drupal.org/node/2805173#comment-11814857 . It does actually support twig when "Use replacement tokens from the first row" is checked and result count > 0. I would like full twig support. why using a powerfull language like twig only for replacing tokens? row "Custom text" fields explicitly support twig, why not header "text area" fields?

I'm curious for arguments why "Text area" supports twig conditionally, but is only designed to parse tokens?

Proposed resolution

  • Let the "Text area" always parse twig, or
  • Add a new "Custom area" that extends "Text area" class "TokenizeAreaPluginBase" and adds twig parsing.

The latter I build as a small custom module, can make a patch of that.

Remaining tasks

Feature request
Status

Active

Version

11.0 🔥

Component
Views 

Last updated about 6 hours ago

Created by

🇳🇱Netherlands keesje

Live updates comments and jobs are added and updated live.
  • VDC

    Related to the Views in Drupal Core initiative.

  • Security

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇳🇬Nigeria chike Nigeria

    As said on #6 admin-level permissions is required for a user to be adding views headers and footers so I am not sure site owners would be giving untrusted users admin roles. For the possible security risks with Twig templates, a warning message could be left on the field.

    There is a legitimate and very powerful use case for allowing Twig syntax on views headers and footers just as they add so much power to views when one uses 'Custom text' field to play around with fields using Twig. It indeed gives so much power to Views, and so also will there be such power added to headers and footers if full Twig syntax is allowed.

    Yesterday I wanted to use Twig if elseif condition to conditionally display a message on the views footer depending on the value of a field, that's when I noticed this wasn't possible. Now I did make a Custom text field and write the Twig conditions on it and then added the field on the footer which ended up achieving the same goal. So if I could still add the condition there somehow why not then allow us do it directly on the footer?

    Weighing the security risks against the use case of the feature, it sure will win to have it enabled and a warning message left on the field to tell people to write Twig with care.

Production build 0.71.5 2024