Views Argument Tokens fail validation in More Link

I think the right thing would be to not expose !1 or %1 exposed as available token, so people don't input any values which are not supported.
Do you think this would make more sense.

Queued this patch for testing against 8.2.0

Simple patch that fixes the problem, running this patch successfully with 8.2.4.

+++ b/core/modules/views/src/Plugin/views/PluginBase.php
@@ -364,17 +364,26 @@ protected function viewsTokenReplace($text, $tokens) {
-        assert('preg_match(\'/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/\', $token) === 1', 'Tokens need to be valid Twig variables.');
+        if (preg_match('/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/', $token) !== 1) {
+          // Tokens need to be valid Twig variables.
+          continue;
+        }
...
-        assert('preg_match(\'/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/\', $top) === 1', 'Tokens need to be valid Twig variables.');
+        if (preg_match('/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/', $top) !== 1) {
+          // Tokens need to be valid Twig variables.
+          continue;
+        }
...
-          assert('is_numeric($key) || (preg_match(\'/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/\', $key) === 1)', 'Tokens need to be valid Twig variables.');
+          if (!is_numeric($key) && preg_match('/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/', $key) !== 1) {
+            // Tokens need to be valid Twig variables.
+            continue;
+          }

We shouldn't remove the assertions since these log errors these but maybe we should do them differently in light of this. And this fix should be tested.

#6 solved the problem for me. My more link doesn't have tokens so I don't understand why it even tries to do any token replacement.

@Michelle

If you are defining a more link then tokens are possible.

I realize they are _possible_ but there aren't any actually there. If there aren't any tokens to replace, why is it trying to use the %1 as a token in the more link when the custom URL is just straight text?

Ok, thanks. I mentioned %1 because that and another one that was a symbol before a 1 (forget which symbol) were the two that it was choking on.

#6 seemed to work for me.

Considering comments by @alexpott in #12, I'd like to throw in this fairly straight-forward solution of filtering out the contextual filter tokens from Twig tokens, as the whole point of the assert checks is that they wouldn't be valid.

Haven't thought this out completely but for me this is a serious bug and I need a solution so I'm going with this one for now.

I've just hit this error, but the root cause seems to be slightly different: my view is working with revisions and I get the error when I add a taxonomy reference field before the text field that is being parsed for tokens.

Specifically, the taxonomy field seems to generate a token named field_my_term-revision_id, i.e. it contains a hyphen, which the regex doesn't allow. Should the taxonomy/revision code be fixed to not use '-' as glue, or should this be added to the regex?

@Andy_Read: try #2831233: Field tokens for "historical data" fields (revisions) contain a hyphen, breaking twig templates and throwing an assertion error

@tacituseu: thanks for the reference!

I have the same error for the core version 8.6.16, but the #21 alone not helping this, but we can modify the #6.
Adding a new patch for 8.6.16

Thanks! #28 works for us.

Thanks, this still needs a test.

Thanks! #28 works for me.

#28 works for us, thanks! I'm just updating to apply it with the 9.5.9 version.

Thanks for patch, generally it works, but I'd like to propose some improvements.

1. The last "continue" is in one more foreach, so I think there should be
continue 2;

2. "array_pop" removes the last element in the array, and it isn't validated in further foreach cycle.

$token_array = [array_pop($parts) => $replacement];

It could be fixed in many ways, like

// Its isn't good from design perspective as variable changes type from sting to array, but works in PHP.
$token_array = $replacement;

or

$token_array = NULL;
// ...
$token_array = [$key => $token_array ?? $replacement];

Adding a new patch with the suggestions.

Was previously tagged for tests which still needs to happen.

Also issue summary isn't super clear with steps to reproduce or proposed solution.

I've spent sometime trying to reproduce this. I've found an issue but it not related to the issue summary explanation of this problem. You get the same error if you have any custom fields that start with a number. Note that this is difficult to do with Drupal via the UI because by default Drupal will prefix field names with field_ but it is possible to alter an entity type to add a base field like '1_something' and then Views will trigger this assertion message if you use views and use the field rewriting feature. I'm going to open a new issue for this specific case and I'm going to postpone this one and ask for more information. The new issue will update the assertion messages to be more helpful and tell you which token is invalid.

I've grepped core and a lot of contrib and I cannot find anything that is causing the old tokens of %1 and !1 etc... to still be used.

Here's the new issue #3548695: Custom fields which start with a number can break views

Since there's been no follow up to #44 going to close out. If still an issue in D11 please re-open

Thanks all.