Extra attributes of the a tag are rendered in the obfuscated format

I upload a patch as well for composer patching the latest release.

The last submitted patch, 3: extra_attributes_of_the_a_tag_are_rendered-3372537-3.patch, failed testing. View results →

Updated the test assertion.

Updated the patch to make sure the styling is applied via the twig estension as well.

@joevagyok thank you! This please needs tests to ensure it works as expected.

@Grevil: FYI I'm not sure this is done correctly and as you'd expect. The goal should be, that the output with spamspan is shown like without spamspan and the obfucation is done in the background.

I read the issue summary and the patch several times and don't really get the point here. For now it looks like a (dirty) workaround to me, so please handle with care. But I might be wrong.

Would be nice to have a good example with expected and actual output...

If unsure, just leave this open for further explanation.

I might have been unclear in the issue description, my apologies. But as I mention, the obfuscation - which is when the email is in an obfuscated format - should remain readable. However, any extra attributes added to the obfuscated a tag is printed, making it unreadable.

@Anybody The "obfuscation in background" - is when JavaScript is not enabled in the browser, the text format and twig filter prints the obfuscated email on the front end which is normalised by JS into a correct mailto link.

You want me to assert the "display" none;" is in place for the span containing the extra attributes?

As discussed in #3372768 🐛 Twig extension strips anchor tags from the processed text Fixed we are looking into the solution to apply the extra attributes over the spamspan element.

@Anybody, I after testing it I have a problem with that, because it will break the look of the frontend since the span element gets the attributes like "class, id, data-xx" which will be rendered with the style sheet rules in place which will cause unexpected results.

@joevagyok thanks. Then I think we have two options:

1. Indeed add these attributes to a hidden pseudo element
2. Prefix the attributes with data-spamspan- so that for example class="xxx" becomes data-spamspan-class="xxx"

I'd vote for the second option! :)

Yes, I agree with the second option. I will dig into that.

As of #16 I'll put this to "Needs work" again.

Ok let's finally make this major, as it's 2/2 of the last important bugs known here...
And with JS disabled the current output, which may be relevant for SEO also, looks really broken.

Uploading patch for composer.

Whao, really nice work again!! +1 from me, Grevil what do you think?

What do you think about ✨ Allow custom spamspan class to make it harder for spambots to detect spamspan Active @joevagyok regarding spambots? I think it's quite unlikely to focus on spamspan, might even be easier to have a crawler with JS enabled? Otherwise, it might not be the worst idea to solve that after this one and add the variables for prefixes and classes... Thats why I' asking ...

I see the point of configurable class names and etc... even though I find it a bit "paranoid". We could definitely consider it as a new feature to what the module has to offer so far.

On the JS crawlers my take is that search engines like Google and Bing use sophisticated crawlers that can interpret and execute JavaScript, just like a real browser.
On the other hand, many "bad bots" like email scrapers, we are providing to protection against, are likely to be more basic and may not execute JavaScript. This is because interpreting JavaScript requires a much more complex and resource-intensive crawler, which makes it inefficient if the goal is to scrape as many websites as possible in a short time, especially only for email addresses in the end of the day...

Works and looks great, thx! Found another bug, while testing this... but got nothing to do with this.

RTBC!

@joevagyok same thoughts here... so the paranoid protection might be something in the middle, that is not *very* helpful, because then it might be cheaper for the crawlers to run JS instead of focussing on spamspan classes? ;D

This might have caused a new issue involving the javascript not converting the data attributes back properly, when having multiple classes set! I created a follow-up issue: 📌 JavaScript not properly clearing the data attributes, when multiple classes are set Fixed .

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