Content tokens are not usable in prefix and suffix

Weirdly enough, while checking the queue and testing tokens in suffix and prefix, they already seem to work. There's a problem with multilingual content though, so will double check that.

Note: the dev branch now has an option to make prefix and suffix textareas, so that at least has been solved.

Moving to bug to make the fixes that are needed. Needs tests a volonte.

Added related issue that added prefix/suffix support initially

This patch has been essential for us, thank you. Are there remaining obstacles (test failures?) to getting this into a ds release? Thanks again.

I'll have a look this week! I'm going to add an option at /admin/structure/ds/settings that allows you to enable this option so that sites who upgrade don't have undesired consequences, even though the impact is probably minimal anyway, but you never know :)

swentel → changed the visibility of the branch 2761767- to hidden.

swentel → changed the visibility of the branch 2761767- to active.

Ok, I've merged parts of the branch, especially the test (which only runs locally though). Afaics, tokens are working now. If anything still is weird, please open up a new issue.

Hello @swentel,

It seems the resulting 32.patch removed the actual token replace. Or did I misunderstood?

Adding another patch

The replace of the tokens already happens in Expert.php, unless there's something else I completely missed as well :)

I can confirm that the moved code from ds.module to Expert.php does NOT do what it is supposed to.

I have run some tests and the Xss::filterAdmin has to come AFTER token expansion, as it was in previous patches.

In my example, I have an image field with expert configuration, prefix:
<a href="[block_content:field_remote_url:uri]">
and suffix:
</a>

In this configuration, after running the following line from ds.module:

$variables['settings'][$wrapper_element_name] = !empty($variables['settings'][$wrapper_element_name]) ? Xss::filterAdmin($variables['settings'][$wrapper_element_name]) : '';

the prefix becomes:
<a href="uri]">

So basically the Xss::filterAdmin cuts the "[block_content:field_remote_url:" breaking the prefix.

Reverting to the previous versions of the code (with the expansion of tokens before the Xss:filterAdmin) brings back the functionality.

Interesting, especially because there's a test which works .. :)

@devarch in your example, that configuration happens on a block type right? Just to be completely sure.

@swentel Yes, I have a block with two fields (image and remote_url) and I am using DS to output the image enclosed in the remote URL.

I didn't look into the tests, but I am guessing if it is a unit test for the Expert.php of course it will work because the tokens will be passed correctly to the function. The problem arises if the prefix/suffix containing tokens are passed to the Xss::filterAdmin that will cut part of the tokens.

Well, the test doesn't use the a tag, but span. Crap! So yeah, that's the problem indeed, I'm testing it with the wrong tags.

Actually, adminTags does allow the a tag, oh well, will test more and add more tests!

The problem is with XSS::filterAdmin

If you try running this in console:

drush php-eval 'print Drupal\Component\Utility\Xss::filterAdmin("<a href=\"[block_content:field_remote_url:uri]\">");'

the output is:

<a href="uri]">

So it breaks the token, just as I saw previously by placing logs in the ds.module. Please see comment #51.

The problem is with XSS::filterAdmin

Ok I get it now. XSS::filterAdmin has always been there, but the problem is that for some reason the code in Expert.php fails to replace the token with the actual value. The token should have been replaced already at this point (which why I was confused since the test is green, but maybe the test is completely wrong too haha)

Will have a fresh look this weekend, thanks for the pointers.

I am looking into Expert.php and I am seeing this:

$wrappers = [
      'lbw' => $this->t('Label wrapper'),
      'ow' => $this->t('Wrapper'),
      'fis' => $this->t('Field items'),
      'fi' => $this->t('Field item'),
    ];

    foreach ($wrappers as $wrapper_key => $title) {
          if (!empty($values[$wrapper_key])) {...

The token expansion/replacement happens down in this loop/if, but prefix and suffix are different fields than the four listed above and their replacement shouldn't be conditioned by the usage of other fields.

Am I missing something?

Oh crap, you are right! Looking at the test, it enables the field item wrapper .. so, the test works by accident.
Looking at the code, the replacement could actually happen multiple times, which is completely unnecessary!
Oh lord, where was my mind :)

Hello everyone! good day. Do we have any update for this?
Can anyone explain what needed to do so we can create a proper MR?