Global Token Replacements is not working correctly in href

Ran into this issue as well. Seems to only happen when the 'tokenize' option is selected for the area AND you want to use the global tokens. Based on that finding in my specific case I rolled up a small patch that seems to fix the issue for me. The patch just runs the global token replacement before the View style `tokenizeValue`. Posting it here to see if it addresses the issue for others, or if there are any issues that could stem from this change that I'm not thinking of.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Thanks for working on this

Issue summary needs to be updated to follow standard issue template

Also will need a failing test case to show the issue.

Issue summary updated w.r.t to standard issue template

Also added failing test case to show the issue.

Needs tests means there should be a test in code.

pooja_sharma → changed the visibility of the branch 11.x to hidden.

pooja_sharma → changed the visibility of the branch 11.x to active.

pooja_sharma → changed the visibility of the branch 11.x to active.

pooja_sharma → changed the visibility of the branch 11.x to active.

7708 is already pointing to 11.x please use that.

I tried to use this MR: 7708 but facing issue , due to which need to create new MR:

Code enhanced with test case, Please review: 8335 MR

Facing issue to push code in this MR: 7708 from IDE even, so worked in MR: 8335

Thanks, took a quick look

Imagine there was probably already a test file we could extend without having a new one. Example AreaTest

But could probably be a kernel test too as the fix is testing the output so doesn't need a fully functional test testing the UI.

Will say shouldn't be using claro as the default theme unless we are testing claro specific bug.

I though of using existing AreaTest file however it has only area text handler along with it is not content type view due to which this checkbox "Use replacement tokens from the first row" field not display, the issue is replicating when we enabled this opt "Use replacement tokens from the first row"

'll add kernel test too, can you please suggest should I need to remove this functional test file fully or need to remove some specific piece of code

Observed existing test file , I believe should use 'stark' theme.

Yea I would remove functional test.

Looking at the kernel handler folder I see a number of Area files if none of those match then could use it's own. Kernel just takes less

Okay Thanks for prompt responses, got it purpose of using kernel as it takes less time to execute.

Anytime. Your comments just came through right when I was checking emails so worked out. If I see it come back will add to my list for quicker review.

pooja_sharma → changed the visibility of the branch 2684251-global-token-replace-tasks to hidden.

pooja_sharma → changed the visibility of the branch 11.x to hidden.

pooja_sharma → changed the visibility of the branch 2684251-global-token-replace-tasks to active.

Added Kernel test case, reused existing eg AreaText Plugin(Rather than generating fresh filteredText one as suggested), in a distinct test file to assess specific scenario.

Please review, moved to NR

Added Kernel test case, reused existing eg AreaText Plugin(Rather than generating fresh filteredText one as suggested), in a distinct test file to assess specific scenario.

Please review, moved to NR

Hiding patch for clarity.

Ran test-only feature to prove the test coverage https://git.drupalcode.org/issue/drupal-2684251/-/jobs/1812202 and shows a failure. So removing that tag.

Applied a super nitpicky :void return on the test.

Looking at the actual fix and change makes sense.

Believe this is good.

Rebased seems fine

Rebased the MR with latest code, seems fine

I considered this from a security point of view and I think that we're still good here as the return will still be XSS filtered as expected - it is just XSS filtering no longer breaks the tokens. Nice fix and test.

Committed and pushed ca4535dd9a to 11.x and ff0f9a93a7 to 11.0.x and 0fedc5820a to 10.4.x and 2afadf4871 to 10.3.x. Thanks!

Backported to 10.3.x as this is a bug fix.

Thanks you so much @alexpott

A heartfelt thank you to @smustgrave for your kindness & exceptional support, I've learned a lot from you.

Automatically closed - issue fixed for 2 weeks with no activity.