Views doesn't parse twig when there are no tokens to replace

I think there needs some discussion around what to be shown if no data as then token will have nothing to replace. Should be show as it is (no change) or just remove or return no data (empty).

Seems to touch on #2665766: {% %} twig syntax is only parsed in text area handler when a {{ }} token is present

Agreed. We've got 4 choices:
1) Always parse twig, but set first row as variables for twig depending on this UI "Use replacement tokens from first row" setting
2) Always parse twig, and always add the first row as variables, abandon the UI setting
3) Make a new setting additional "Process the input using Twig", and only offer the "Use replacement tokens from first row" if that is checked
4) Replace the current setting with a single "Process the input using Twig" setting

I'd suggest #2 is best - what's the point of these UI settings? Everything is presumably cached to the 11th degree, so I imagine there's no performance issue, and as long as we support Twig escaping then the twig parsing is not blocking anything a sitebuilder might want to do.

Twig syntax would only be parsed when the data is available or the token is available or present within the syntax. Please try these steps:

1.create a view and display it.
2.Should add a global filter text field to the header.
3.Replace the token with the first row. The first row as a variable should work properly.

If the data filter has nothing to replace if no data, then we should set something like no data or empty value or a message.

I think this is still valid if you want to use some twig syntax on a general header, even to be shown regardless of results/no results.

Agreed with #10. Always processing Twig empowers sitebuilders more, provides more consistency for developers, and makes for a simper easier-to-maintain and test codebase.

And also, when it says that it works "simliar to the global text on fields", there you can use twig, so that's what I was surprised when it didin't work there.

I just want to comment that I kind of sorted this out by using: https://www.drupal.org/project/twig

So it looks like the inconsistency is simply due to a micro-optimisation to quick return when there are no tokens.
This actually covers more scenarios than simply having no results (such as showing 'Content' instead of 'Fields') so I have updated the title accordingly.

I would say that the expected behaviour of checking 'Use replacement tokens from the first row' is that it should always render twig (rather than render twig in certain conditions but sometimes dump the twig as plain text) so i have attached a patch to fix this 'bug'.
IMO we need Twig to be able to do things 'properly' in views, especially with no results i.e. adding a simple 'Add node' link to the header:

<a href="{{ path('node.add_page') }}">{{ 'Add Node'|t }}</a>

This should probably have a simple unit test and the checkbox should be updated to explicitly state that it well render Twig as well but I'm afraid I don't have any more time for this now sorry.

I think there probably is merit in the higher level discussion around this checkbox but for now though I would call this is a simple bug in it's current state and further high-level discussion should probably go to a new issue so this can progress for now (especially as any changes to the checkbox are likely to be a breaking and therefore better suited for D9).

Patch from #14 does not work for me. Only visible change: The raw twig token is no longer displayed on the final empty view.

I have the problem with Views 8.6, when Views doesn't parse twig in header text, when View have no argument in url, if I fill argument - twig works, if remove - stops working. Is this same issue, or other?

I was trying to get the "Add Page" link in the header to work with the twig patterns, and it seems I ran into this issue. Applying the patch in #14 seems to have solved the issue for me.

Steps to reproduce from a fresh install of Drupal 8.9 standard profile with no nodes:

• Create a new view - Show Content of type: Basic page... and Create a page
• Add a header: Global: Text area
• Check "Display even if view has no result"
• Check "Use replacement tokens from the first row"
• Enter "{{ title }}" into the content
• Apply
• Observe the literal string "{{ title }}" in the header. Expect nothing printed.
• Save the view
• View the view page
• Observe the literal string "{{ title }}". Expect nothing printed
• Add a Basic page node
• View the view page
• Observe the literal string "{{ title }}" in the title. Expect the title of the 1st node
• Edit the view
• Under Format -> Settings check "Force using fields"
• Apply
• Observe the title of the 1st node in the header (linked to content) as expected
• Delete all the pages
• View the view page
• Observe the literal string "{{ title }}". Expect noting printed

I'm not sure what's next here. I think maybe running the existing tests to make sure it doesn't cause regressions and developing tests for this issue? Neither of which I am familiar with how to do.

Needs Reivew to run the patch through current tests.

Tested on 9.1.8, the twig in header/footer is not parsed (my view displays teasers)

Patch #14 works for me when adding the "Global: Unfiltered text" under "NO RESULTS BEHAVIOR".

#14 works for me in both header and no results behavior using unfiltered text with fields or teasers in 9.3.14 with the following twig that does require the twig tweak module

{% set blog = drupal_token('current-page:query:blog') %}
{% set keys = drupal_token('current-page:query:keys') %}
{% set filtered = FALSE %}
{% set kfiltered = FALSE %}
{% set bfiltered = FALSE %}
{% set dfiltered = FALSE %}
 {% if arguments.created_year_month %}
  {% set filtered = TRUE %}
  {% set dfiltered = TRUE %}
{% endif %}
{% if '[' not in keys and keys|length %}
  {% set filtered = TRUE %}
  {% set kfiltered = TRUE %}
{% endif %}
{% if  '[' not in blog and blog|length and blog != 'All' %}
  {% set filtered = TRUE %}
  {% set bfiltered = TRUE %}
{% endif %}
{% if filtered %}
<div><strong>Results</strong>
  {% if kfiltered %}
<span><strong>for keyword</strong>: {{ keys }}</span>
  {% endif %}
  {% if bfiltered %}
<span><strong>in Blog</strong>: {{ drupal_field('title', 'node', blog) }}</span>
  {% endif %}
  {% if dfiltered %}
<span><strong>for Date</strong>: {{ arguments.created_year_month }}</span>
  {% endif %}
</div>
<div><a href="/blogs">Reset Results List</a></div>
{% endif %}

Setting back to needs review since it looks like this has been an issue for a while

#14 works for me in header, footer and no results using unfiltered text with fields in 9.3.14.

What I found odd is that I need to have a substitution that works before full twig works. Otherwise I wind up with the unevaluated twig expression. This could be an issue with twig substitution rather than the this patch.

<div class="none_{{ raw_arguments.uid }}"></div>

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.

#14 didn't work for me on Drupal 10.1

Added a test area to a view
Added {{ 'fail'|trans }} to the text area
Would expect to see nothing but renders like I do if I place the same code in a twig template.

Also was previously tagged for tests so that will still need to happen as well

I tried the patch on php 8.1 and drupal 9.5 but it didn't work, the {{"my text"|t }} still appears as is

The patch no longer applies to Drupal 9.5.9

updated patch so it works with Drupal 9.5.9

Fix coding style error in patch #32.

Here's a patch for 10.1.3 - yes it has coding style errors (its not going to be committed w/o tests anyway so ¯\_(ツ)_/¯ ).

Patch is designed to show that running $text through Xss::filterAdmin when the $tokens var is empty is what causes the issue. I may be totally mistaken or misunderstanding something, but the $build runs the xss filter anyway at return Xss::filterAdmin($children);, so I'm not entirely clear why showing raw twig to users when results are empty is necessary but again ¯\_(ツ)_/¯

And moreover - patch is to allow people who have this issue to update to 10.1.x without showing twig syntax to users (ie what my PM/UX manager referred to as "cool gobbly gook")

Just adding a re-roll of #33 for d10.1

I've tried the patch on D10.1.x but it seems it has some problems:

If I print in the view header using unfiltered text :

       {% if 1 > 0 %}         hello       {% endif %}
       {{ ""|t}}

Correctly replace the twig.

However,

       {% if 1 > 0 %}  hello  {% endif %}

Does not replace the twig.

What's more, if I use the Global Text Area, and thus a input area with a text format and CKEditor,

       {% if 1 > 0 %}         hello    {{ ""|t}}     {% endif %}

is replaced by

    {% if 1 > 1 %} hello  {{ ""|t}} {% endif %}

Even if writing it in the "source code" mode of CKEditor (the > is html escaped).

That cause a server error on the error on the view page:

Twig\Error\SyntaxError: Unexpected character "&" in "__string_template__f605a68c7565a3509e2a3d658d6b70a7" at line 1. in Twig\Lexer->lexExpression() (line 376 of /var/www/html/vendor/twig/twig/src/Lexer.php).