{% %} twig syntax is only parsed in text area handler when a {{ }} token is present

Moving to right component/project.

+++ b/core/modules/views/src/Plugin/views/style/StylePluginBase.php
@@ -231,7 +231,7 @@ public function getRowClass($row_index) {
   public function tokenizeValue($value, $row_index) {

There is another tokenizeValue method on core/modules/views/src/Plugin/views/field/FieldPluginBase.php

Shoud this check be applied there too?

New patch!

Thanks!. But we need some tests now.

Here i upload two new patches.
One with just the test and then one with the test and the old patch.

Thanks a lot for adding the tests!

1. +++ b/core/modules/views_ui/src/Tests/AreaUITest.php
   @@ -0,0 +1,42 @@
   +    $this->drupalPostForm(NULL, ['options[empty]' => 'checked' , 'options[tokenize]' => 'checked', 'options[content]' => '{% if title %} This is the title: {{ title }} {% endif %}'], 'Apply');
   

   Nice, I think

2. +++ b/core/modules/views_ui/src/Tests/AreaUITest.php
   @@ -0,0 +1,42 @@
   +    $this->assertNoText(t('{% endif %}'));
   +
   +  }
   

   Nitpick solveable before the commit: let's remove this empty line

+++ b/core/modules/views_ui/src/Tests/AreaUITest.php
@@ -0,0 +1,42 @@
+    $this->assertText(t('This is the title'));
+    $this->assertNoText(t('{% endif %}'));

This shouldn't be wrapped with t() - it's never ever translated.

Is this fix going to be pushed in the next release?

Hi Alex Pott,

As suggested in #10,
I have removed the t functions .

+++ b/core/modules/views_ui/src/Tests/AreaUITest.php
@@ -0,0 +1,42 @@
+    $this->assertText('This is the title');
+    $this->assertNoText('{% endif %}');

How is that a bug? This more reads like a feature for me. Can someone clarify that?

dawehner, I can't really speak for the original person who opened the ticket, but the issue for us is that we cannot use TWIG within the "Global: Unfiltered text" field type within, for example, the HEADER section. We can and do use TWIG in "Global: Custom text" fields within the FIELDS section, which is incredibly useful. We'd like to dynamically build our header content based on the page/view's context, but are simply unable to do that right now because of this issue. As a result, we have to build multiple separate views that are the exact same except for their different hard-coded header HTML, when we should be able to consolidate them into a single view that dynamically generates the header HTML (via TWIG) based on the context. IMO, the more places we can use TWIG within the UI, the better!

This seems to be working now in Drupal 8.1.9

@xeM8VfDh
Thank you for trying it out again! I'm glad that this works now. Do you mind trying out 8.2.x and maybe even 8.3.x
It would be great to be 100% sure that stuff is actually working ...

@dawehner If I get a chance to spin up those environments, I will and keep you all posted.

This issue is not fixed just yet. Tested on a fresh stable (8.2.6) and on 8.4.x.

The patch in #12 fixes the basic case. There are some problems with the patch though.

1. The included test does not cover the change introduced in the patch. The test replacement includes both {{}} and {%%}. There should be another test replacement with just {%%}. eg. {%if true%}is true{%endif%}
2. The Twig syntax in "Global: Unfiltered text" does not work when the view does not display fields. eg. Show: Content | Teaser

#20.1 Very true, having a test of what happens without {{ }} is crucial

#20.2 That should be a separate issue? (although have you tried the 'Force to use fields' setting and a hidden field?)

It also raises a bigger question, of why do we have to check "use tokens from first row" to enable Twig parsing at all. It's perfectly possible to use Twig for things that don't require field values, like showing/hiding something depending on the current day of the week. Ultimately perhaps token replacement needs to be treated as an aspect of twig parsing. But it looks like that kind of bigger refactoring should be part of #2396607: Allow Views token matching for validation (and remove dead code).

This seems related/touching on #2858392: Views doesn't parse twig when there are no tokens to replace

Just rerolled #12

I added a use Drupal\Tests\views_ui\Functional\UITestBase; statement in the test (so it would actually run) and replaced the deprecated functions on the test.
I also tried to address the comment #21.

Reviewed and tested without any problems. Seems good to me.

1. +++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
   @@ -344,7 +344,7 @@ public function elementClasses($row_index = NULL) {
   -    if (strpos($value, '{{') !== FALSE) {
   +    if (strpos($value, '{{') !== FALSE || strpos($value, '{%') !== FALSE) {
   
   +++ b/core/modules/views/src/Plugin/views/style/StylePluginBase.php
   @@ -228,7 +228,7 @@ public function getRowClass($row_index) {
   -    if (strpos($value, '{{') !== FALSE) {
   +    if (strpos($value, '{{') !== FALSE || strpos($value, '{%') !== FALSE) {
   

   We should use str_contains() it's more readable and comes with PHP 8.0 (and we have a polyfill for PHP 7 in D9).

   But also are we concerned about existing views which already have {% in the text but don't want it to be interpreted as Twig. This feels very tricky. Not sure what to do here because I've definitely been caught out by assuming {%

2. +++ b/core/modules/views_ui/src/Tests/AreaUITest.php
   @@ -0,0 +1,77 @@
   +  /**
   +   * Undocumented variable.
   +   *
   +   * @var string
   +   */
   +  private $id;
   

   Having test that says Undocumented variable is a bit different. How come we don't say something like Test view ID.

3. +++ b/core/modules/views_ui/src/Tests/AreaUITest.php
   @@ -0,0 +1,77 @@
   +    $this->drupalGet($view->toUrl('edit-form'));
   

   Given both tests with $this->drupalGet() I think this is not needed.

Updating patch as suggested in comment #38

+++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
@@ -345,7 +345,7 @@ public function elementClasses($row_index = NULL) {
-    if (strpos($value, '{{') !== FALSE) {
+    if (str_contains($value, '{{') !== FALSE || str_contains($value, '{%') !== FALSE) {

+++ b/core/modules/views/src/Plugin/views/style/StylePluginBase.php
@@ -228,7 +228,7 @@ public function getRowClass($row_index) {
-    if (strpos($value, '{{') !== FALSE) {
+    if (str_contains($value, '{{') !== FALSE || str_contains($value, '{%') !== FALSE) {

The !== FALSE is unnecessary now.

@alexpott, thanks.

Updating patch as suggested in comment#40

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

The issue summary could use an update using the default template. What was the proposed solution to fix the problem? Screenshots of the error would be useful too as this seems to be a UX issue.

Updating the issue summary with more information.

Patch needs to be updated for 11.x

Patch for Drupal 11.x