SpamSpan breaks markup

I think we need details here first and find out what exactly breaks and why. Might also have local reasons. If not, we should first add tests for what should NOT break.

As there are errors in the console, I think the output is what happens because of 🐛 Extra attributes of the a tag are rendered in the obfuscated format Fixed if JS isn't executed.

Downgrading to beta2 fixes the issue.

composer require drupal/spamspan:3.0.0-beta2 for anyone running into this issue.

Can not be reproduced, it's clearly a JS error, but I think must be from another module or theme... then resulting in 🐛 Extra attributes of the a tag are rendered in the obfuscated format Fixed

I could finally replicate the issue! It is actually quite simple to replicate, too...

If the anchor tag has a child Element containing NO text, the markup just goes wild. There are also different results based on the child element.

E.g. when having an icon element as a child, which does NOT have text:

<a class="test-anchor" href="mailto:info@webks.de">
  <i class="test1"></i>
</a>

The markup will look like this:

Note, that this is different from 🐛 Extra attributes of the a tag are rendered in the obfuscated format Fixed .

Created a test, showing the problem. It is already broken before even being decoded by the javascript (problem on php side).

This is issue got introduced through changes done in 🐛 Using saveHTML() breaks other links Fixed . We should revert these changes here and try to additionally find a different fix for 🐛 Using saveHTML() breaks other links Fixed here.

Alright, this should do it for now, but even if the text was altered, "saveHTML" shouldn't do any escaping mentioned in 🐛 Using saveHTML() breaks other links Fixed

<a href="[media/file/1]">[media/file/1]</a>

Changes are looking good, would have done the same, however it fails for a really weird reason.

@joevagyok the key idea is to only touch markup where it's really needed to safe us from things like double escaping where ever possible and for best performance. But yes, maybe needs to be done differently. To me the existing code looks like anything is run thought DOMDocument and we should try to not do that.

That is exactly the idea I based the solution on.

Perfect, sorry for the overlap :D

LGTM! I'll finish this issue adding two tests, to make sure, we do not escape any special characters outside / inside the anchor tags.

Ok done, waiting for final review.

For me it is good to go.

Perfect! Let's wait for the tests to go green and then push!

All green!

Great work guys, thank you. Please tag a new release, if it's well tested! :)
Hope we won't have a bad weekend though ;D

Also confirming that #25 fixes the issues I'm seeing which are the same as from #7.

Would be nice to get this into a new release.

@fenstrat thank you! As others are running into the issue, I'll tag 3.1.2 now! :)

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