When adding a custom text field to a view with twig conditions (if) or twig flow control (for), it's not getting processed. For example:

  1. Create a view, display page
  2. Add a global unfiltered text field to the header
  3. Check use replacement tokens from the first row
  4. Add content with a Twig condition between {% %}
  5. Go to the view page and you'll see your twig code within the HTML

Comments

yioPa created an issue. See original summary.

yioPa’s picture

Proposed solution, adding a patch here.

dagmar’s picture

Project: Views » Drupal core
Version: 8.x-3.x-dev » 8.1.x-dev
Component: Miscellaneous » views.module
Status: Active » Needs review

Moving to right component/project.

dagmar’s picture

Status: Needs review » Needs work
+++ 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?

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nicolas.rafaelli’s picture

Status: Needs work » Needs review
FileSize
1.47 KB

New patch!

dagmar’s picture

Status: Needs review » Needs work
Issue tags: -Twig content views plugins +Need tests

Thanks!. But we need some tests now.

nicolas.rafaelli’s picture

Status: Needs work » Needs review
FileSize
1.58 KB
3.05 KB

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

dawehner’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Need tests

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

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ 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.

xeM8VfDh’s picture

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

pashupathi nath gajawada’s picture

Status: Needs work » Needs review
FileSize
3.04 KB

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 %}');
dawehner’s picture

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

xeM8VfDh’s picture

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!

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xeM8VfDh’s picture

This seems to be working now in Drupal 8.1.9

dawehner’s picture

@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 ...

xeM8VfDh’s picture

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

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ccmorris’s picture

Status: Needs review » Needs work

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
jonathanshaw’s picture

Title: Views plugins don't accept Twig flow within content » {% %} twig syntax is only parsed in area handler when a {{ }} token is present

#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).

joelpittet’s picture

Issue tags: +Twig
Lendude’s picture