- Issue created by @cburschka
- π¨πSwitzerland cburschka
On testing further, it does seems to affect a lot of markup besides style - for example, one of my macros should do the following:
Turn this
[spoiler]Hidden text[/spoiler]
into the output of this twig template:
{% set id = random() %} <input id="xbbcode-spoiler-{{ id }}" type="checkbox" class="xbbcode-spoiler" /> <label class="xbbcode-spoiler" for="xbbcode-spoiler-{{ id }}">{{ tag.content }}</label> {% endapply %}
with this CSS attached:
input.xbbcode-spoiler:not(:checked) + label.xbbcode-spoiler, input.xbbcode-spoiler:not(:checked) + label.xbbcode-spoiler * { color: black; background: black; } /* Hide the checkbox. */ input.xbbcode-spoiler { display: none; }
This works normally in content:
<input id="xbbcode-spoiler-1375131070" type="checkbox" class="xbbcode-spoiler"> <label class="xbbcode-spoiler" for="xbbcode-spoiler-1375131070">Hidden text</label>
But (in 10.0.2) the sample output on /filter/tips removes everything except the text of the label:
Hidden text
Class and data attributes I tested seem to go through, but they're not really usable in this context. I suppose the markup could be inserted dynamically by a script, but that seems an overly cumbersome way to circumvent the filter.
- πΊπΈUnited States cilefen
Can you determine the core version that introduced the new behavior, and from there, the issue that caused the change?
- π¨πSwitzerland cburschka
Well, this was a wild goose chase :D
After inexplicably finding this same behavior as far back as 8.6, I finally realized the issue is in my test module: My actual module here returns the result of a
\Drupal::service('renderer')->render()
call, rather than a string. The renderer, of course, returns aMarkup
object, which allows the markup and styles to pass through unscathed.The regression therefore was not in core - it was caused by adding return type hints in my module.
Drupal\filter\Plugin\FilterInterface::tips() asks for the return type to be "string|null" in PHPDoc, and without type-hints, this polite suggestion causes no problem when returning a Markup object.
If we add string as a strict type hint, though, PHP helpfully converts the Markup object back to string before returning it, causing it to be sanitized. :D
In summary, in core this seems to be just a documentation issue for now - all such methods that expect render output should mention Drupal\Core\Render\MarkupInterface as a possible return type alongside string. Eventually as strict type hints get introduced in core (see π± [Meta] Implement strict typing in existing code Active ) this could become more critical.