Only first element tag in configuration form is rendered in title on Drupal 10.2

I was able to reproduce the error following the steps. I did some debugging and found that the return array ($tags) in HtmlTitleFilter::getAllowedTags() only contains the 'sup' element. It should contain all three tags in the config.

I need to look through it more to understand why this happens. I suspect there's something buggy with the fetching of the body child nodes right above.

You can add something hacky like this to work around the issue for now, but I'll try to provide a better solution if I do find it:

...
$tags[] = 'sub';
$tags[] = 'span';
return $tags;
}

I did think about something along the lines of #3 but then thought that isn't an ideal scenario as this module filters markup to prevent XSS vulnerabilities as stated in the project description.

The change in patch #3 looks like it removes that safety net.

One other thing I noticed in my debugging was that it looks like this line doesn't include the correct amount of nodes in the DOMNodeList object after upgrading to 10.2:

$body_child_nodes = Html::load($html)->getElementsByTagName('body')->item(0)->childNodes;

If I change it to the following (using a wildcard rather than 'body') then it returns the tags specified in the configuration form, but because it's loading all nodes you also get 'html', 'body' etc:

$body_child_nodes = Html::load($html)->getElementsByTagName('*')->item(0)->childNodes;

Could be a starting point? I'm not really sure what's changing under the hood at that point at the moment.

as another workaround, in your settings, close the HTML tags that need closing. E.g., "
".

This error seems to be caught by the automated tests as well see the latest build https://git.drupalcode.org/project/html_title/-/jobs/669321. I am also hesitant about #3. Upgrading the priority of this one and will tackle it next time I get a chance.

Alright, a few things:

1) #3 is a perfectly valid solution. it's a quick Regex way to stip off the outsides of the tag. It just made me jumpy since this was in the Filter service, but it's simply grabbing the tag names from the configuration. Something changed in the HTML parsing class that made this quit working. I don't know that this method is any less secure honestly.

2) All the tests pass with this fix (including the unit test around the getAllowedHtmlTags(). You can see this on https://git.drupalcode.org/project/html_title/-/jobs/669556.

I'm going to call this one good.

Pushing out in a new release.

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