Content tokens are not usable in prefix and suffix

I need to test this that everything still works as expected.
I need to be sure the token replacements don't break allowed html tags.

The patch did not work for me when using a prefix like:

<a href="[node:url:absolute]">

but I changed the patch to make that work. The tokens need to be replaced first and then the text can be filtered.

I tested this with DS 8.x-3.0-rc1.

Forgot the interdiff in the last comment so here it is.

Whoops. Diff'ed the wrong direction. Let's try that again.

This needs a test :)

Added a test

Kristen's patch in #3 applied and working on DS8.x-3.0 + D8.3.2
Thank you

The patches in 3 and 7 no longer apply to the 8.x-2.x branch. They do apply to the 8.x-3.x branch. I did find a few issues with the patches but nothing critical.

1. +++ b/ds.module
   @@ -1075,10 +1075,22 @@ function template_preprocess_field__ds_field_expert(&$variables) {
   +  // Replace tokens in the prefix and suffix.
   +  $prefix = \Drupal::token()->replace(
   +    $variables['settings']['prefix'],
   +    array($variables['element']['#entity_type'] => $variables['element']['#object']),
   +    array('clear' => TRUE, 'sanitize' => FALSE)
   +  );
   +  $suffix = \Drupal::token()->replace(
   +    $variables['settings']['suffix'],
   +    array($variables['element']['#entity_type'] => $variables['element']['#object']),
   +    array('clear' => TRUE, 'sanitize' => FALSE)
   +  );
   +
   

   Some duplicated code here.

2. +++ b/tests/src/Functional/FieldTemplateTest.php
   @@ -467,6 +467,32 @@ class FieldTemplateTest extends FastTestBase {
       * Tests XSS on field templates.
       */
   +  public function testDsFieldPrefixSuffix() {
   

   The doc block title is not correct.

3. +++ b/tests/src/Functional/FieldTemplateTest.php
   @@ -467,6 +467,32 @@ class FieldTemplateTest extends FastTestBase {
   +      'fields[body][settings_edit_form][third_party_settings][ds][ft][settings][suffix]' => '</a>',
   

   This should be updated to include a test for a token in the href attribute like mentioned in #3.

Here is a new patch against the 3.x branch and an interdiff between it an #7. I'll include a patch for the 2.x version next.

1. +++ b/ds.module
   @@ -1075,22 +1075,19 @@ function template_preprocess_field__ds_field_expert(&$variables) {
   +  // Process the prefix and suffix.
   +  foreach (['prefix', 'suffix'] as $wrapper_element_name) {
   +    // Replace tokens.
   +    $wrapper_element = \Drupal::token()->replace(
   +      $variables['settings'][$wrapper_element_name],
   +      [$variables['element']['#entity_type'] => $variables['element']['#object']],
   +      ['clear' => TRUE, 'sanitize' => FALSE]
   +    );
   +
   +    // In order to allow HTML we need to filter XSS the output of the
   +    // prefix and suffix.
   +    $variables['settings'][$wrapper_element_name] = XSS::filterAdmin($wrapper_element);
   +  }
   

   This is the same logic as in #7 but without duplicated code.

2. +++ b/tests/src/Functional/FieldTemplateTest.php
   @@ -478,16 +481,18 @@ public function testDsFieldPrefixSuffix() {
   +      // Tests that token substitution works in the href attribute in links.
   +      'fields[body][settings_edit_form][third_party_settings][ds][ft][settings][suffix]' => '<a data-ds-test-token-href href="[node:url]"></a>',
   

   This tests that the issue reported in #3 is resolved. Note that node:url:absolute was not used because that would require the contrib token module. The cause of the issue in #3 was core's filtering of allowed protocols in the href attribute, so testing for node:url is enough.

Note that tests will fail for #10 because the patch is for the 8.x-3.x version but I couldn't figure out how to mark it for testing against the 3.x version.

Here's a patch for the 2.x version.

Here's the same patch again as in #10 but marked to test against the 3.x version.

Here's another patch for the 8.x-2.x branch which should pass testing.

Alright, here's one more attempt to get a passing test for the 8.x-2.x branch.

Looking good

Patch in #15 doesn't work in a multilingual environment. So I've updated the patch for the 8.x-3.x branch to support translations too.

Please find attached updated patch to add multilingual support to the expert field template plugin.

Some observations to #15 and #24

diff --git a/ds.module b/ds.module
index 4d70ede3..716cd083 100644
--- a/ds.module
+++ b/ds.module
+    $wrapper_element = \Drupal::token()->replace(
+      $variables['settings'][$wrapper_element_name],
+      [$variables['element']['#entity_type'] => $variables['element']['#object']],
+      [
+        'clear' => TRUE,
+        'langcode' => \Drupal::languageManager()->getCurrentLanguage()->getId(),
+        'sanitize' => FALSE,
+      ]
+    );

Do we need 'sanitize' => FALSE,? From the docs, there is no parameter with that name, the user is responsible for sanitizing the output.

The 'langcode' => \Drupal::languageManager()->getCurrentLanguage()->getId() can have a potential problem. From the docs getCurrentLanguage() without parameters defaults to \Drupal\Core\Language\LanguageInterface::TYPE_INTERFACE, which is the current language of the interface not of the content, which in turn I don't think is the desired effect.

To get the actual content language the code block should look like:

    $wrapper_element = \Drupal::token()->replace(
      $variables['settings'][$wrapper_element_name],
      [$variables['element']['#entity_type'] => $variables['element']['#object']],
      //['clear' => TRUE, 'sanitize' => FALSE]
      ['clear' => TRUE, 'langcode' => \Drupal::languageManager()->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId()]
    );

with a

use Drupal\Core\Language\LanguageInterface;

at the beginning of the .module file.

With these modifications everything works as expected.

Here is the patch from #24 updated with the observations from #25 and fixed the 14 coding standard errors from the ds.module file, as reported by the phpcs --standard=Drupal.

I have been using the patch in #15 successfully for a few months now.

However, recently, I found myself having to add multiple tokens to the "Suffix" field, as defined in ds/src/Plugin/DsFieldTemplate/Expert.php

While the suffix field in that template has a size declared, but no maxlength, I was finding a maxlength of 128 being applied to my Prefix and Suffix fields on that Expert template.

After some homework, I found file.settings.yml in my configuration:

description:
  type: textfield
  length: 128
icon:
  directory: core/modules/file/icons

If we commit the allowance of tokens in Prefix and Suffix, it may be prudent to consider a long maxlength ~or~ to convert those to a textarea in ds/src/Plugin/DsFieldTemplate/Expert.php.

So, is there any hope that this bug will be fixed? There are working patches attached, what's holding this?

Can someone from the DS developers have a look? It's almost three years since this bug was opened.

For the record, this is a feature request not a bug.

@aspilicious Since it gives you the option of browsing available tokens when customizing the field template, it clearly gives the message that you can use tokens in the prefix and suffix fields. Otherwise why would you browse those tokens?

If it was not an intended/supported behavior, you have to recognize that it's pretty confusing. More over the help message from prefix and suffix don't mention that tokens are not allowed/supported.

So either way this sounds more like a bug and not a feature request.

Leaving all this aside, even if it's a feature request, it is a very useful one, with solutions proposed and implemented (and tested in my case on live deploys) so the question remains: what's holding this back from being included in the release?

The test suite needs to be expanded with various test examples.
So yes you're right there is no comment that tokens are not allowed but that is easily added.

And comment #27 is completely ignored.

Setting to needs work for the tests.

The patch in #26 won't apply after 3.7.0 so I took a stab at rerolling it. I haven't tested functionality.

Hey all, applied patch from #32 and it seems to be working fine for me.
Thank you for this thread as it helped me solve my issues.

The new patch is great thank you! @karenann @aspilicious concerning #27, which is not directly related but VERY quickly becomes an issue once this patch lands, I have put together #3131480: Use a Textarea for Prefix and Suffix to address that.

#32. works. Thanks

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