Double-escaped HTML entities in group titles

The bug was originally introduce with this fix : https://www.drupal.org/node/2698405
When SafeMarkup::checkPlain() was replaced by Html::escape().

Html::escape returns a string, whereas SafeMarkup::checkPlain() return an MarkupInterface object (like $this->t() or Markup::create()), so the "#title" key should contain a MarkupInterface object.

Now why this get double-escaped for the "Tab" widget (which is in fact a "Details" with additional features) and not for a "Fieldset" widget even if they have the same title value as input ?
You can find the answer in the "/core/includes/form.inc" file of Drupal Core.

For a "Details" widget, the title gets generated like that :
$variables['title'] = (!empty($element['#title'])) ? $element['#title'] : '';

When "Fieldset" widget generates the title like that :

if (isset($element['#title']) && $element['#title'] !== '') {
    $variables['legend']['title'] = ['#markup' => $element['#title']];
}

(Notice how the value is wrapped in an array with the key "#markup" to mimic a MarkupInterface object)

If you try to replace
$variables['title'] = (!empty($element['#title'])) ? $element['#title'] : '';
by
$variables['title'] = ['#markup' => (!empty($element['#title'])) ? $element['#title'] : ''];
you'll see it do the trick too.

So may be, it's a Drupal Core issue originally ; but I suggest every variables given to Twig templates to be MarkupInterface objects to not rely on the Drupal Core behavior, as it was before the bug was introduce.

+1 for the "Markup::create(Html::escape())" instead of the simple "Html::escape()", it does the job, but there are probably other places to tweak.

As the titles are supposed to be translatables, the t() method call can be the solution because it returns a MarkupInterface compatible object.
Instead of escaping the translated string, which is considered safe as it's been through locale_string_is_safe(), we should escape the label before translating.

Please, find an attached patch for all the existing field_group plugins.

Here's a patch that allows me to pop HTML into the title of my HTML element. Mainly because I need this and needed somewhere to host the patch.

This should probably be a new plugin in a new module somewhere.

Actually, that patch was wrong sorry.

@Steven Jones you really should open a new issue because you're probably not the only one that would need to put HTML in the groups titles.
(and, you should not pollute this issue posting new, incomplete, patches as it could confuse the maintainers)

I tried patch from https://www.drupal.org/node/2822299#comment-11789150 as well as from https://www.drupal.org/node/2822299#comment-11838595 - but with both patches applied the field group title is not translated anymore.

@tobiberlin as the strings are given to the translation engine after having been sanitized, it's possible that you have to re-translate them in the UI. Can you try to check in the translation UI if the strings are there, please?

I just created a new field group (HTML element) to check. I find the title of my field group in the translataion UI and can add the translated string but in frontend it does not change in my case. I tried cache rebuilding, visiting the page in English and German but nothing changes - the title of the field group remains English

I propose a radically different approach: #2846617: Do not translate field group labels using interface translation.
This issue only solves double escaping, but still strings get translated. Labels that have translated interface strings, still get translated with strings from a different context (the interface).

@Sutharsan That's interesting. I think we can close this issue as duplicate as yours also solve the problem.

Patch from #4 works for me!

#14: the related issue is not about removing translations, it's about removing translations from the "interface translations". In D8, we have a brand new Config Translation module in the Core that should already allow to translate field group labels. In fact, there is nothing right now in field_group to interface with this module and that's what should be changed. Finally, this issue could be commited right now to fix the double-escapment issue but it might be a temporary workaround.

Given the review in #15
Given my comment in #16 about this patch being a temporary workaround while there is no way to use Config Translation for field groups
I think the solution in #4 needs to be pushed as a temporary fix for this issue then, when Core is ready, we'll be able to remove translations to rely on Config Translations.

I rerolled the #4 patch to ensure it can be applied so let's review it one last time :)

When testing these patches also use #2652934: Horizontal tab title is not properly retrieved from the details form element and all title html attributes are lost to fix the display of horizontal tab titles. That issue also needs review, see #15.

For me that patch was enough to make tab titles show HTML. The patch from THIS (12343286) issue was not required to make the HTML code appear.

Patch worked for me. +1

I can be pragmatic myself. But I tend to agree with the uckyness feeling around the abuse of the translation calls.

I know this issue was initially raised against the 1.0-dev branch, and is closed. I'm only adding this comment here because the proper/appropriate steps are being taken for the 3.x-dev branch and raising another issue/duplicate for this 'temporary fix' just seems cruel...

For anyone running the 8.x-3.0-beta1 branch and not able to update to 3.0-dev, this may save you some time.

I was having issues applying the #18 patch in this thread (aka, patch failed to apply) in order to maintain displaying an & in a field group label. I found the patch for field_ui.inc file specifically was the issue, line 144 became line 161 in the patch file I manually created. I have tested it by downloading the .tar from the module homepage and simply running git apply
.

Basically I am applying the patch for ^3.2 which is compatible with Drupal 9. If anyone running the 8.x-3.2 branch it maybe helpful.