Ian,
Glad you sorted this out and high five for thinking of the CSS trick to inject the envelope.

Now that it's working, I wanted to say that using the <cms:cloak_email> tag directly might be better for your use case.

The email_guardian tag was meant to protect users from themselves. You wrap it around content that the client is entering in case they might put in an email address without understanding the dangers. In your case you know it's an email, so there's no need to add the extra layer of the email_guardian.

Code: Select all

<i class="bx bx-envelope"></i>
<cms:cloak_email email="<cms:get_custom_field 'header_email_link' masterpage='globalstwo.php'/>" title="Email: <cms:get_custom_field 'header_email_link' masterpage='globalstwo.php'/>" />

Thank you, I did try the cms:cloak_email method first going by viewtopic.php?f=4&t=7044 but it would not show the email address using shortcodes, all I could think was that shortcodes did not like being in my includes/header.php file as tried all different ways to get the email address to show but wouldn't work and would not show the email address on the front end

I tried it again using your code Tim and it works now, thank you

[trendoman]

@tim, @ian
I just got an idea - what if tag cms:cloak_email would be a tag pair? A modification will ensure that anything between tags would be encoded and placed between <a></a> tags as HTML.

Code: Select all

<cms:cloak_email email="<cms:get_custom_field 'header_email_link' masterpage='globalstwo.php'/>" >
    <i class="bx bx-envelope"></i>
    Email: <cms:get_custom_field 'header_email_link' masterpage='globalstwo.php'/>
</cms:cloak_email>

Simple and efficient?

@tim, @ian
I just got an idea - what if tag cms:cloak_email would be a tag pair? A modification will ensure that anything between tags would be encoded and placed between <a></a> tags as HTML.

Code: Select all

<cms:cloak_email email="<cms:get_custom_field 'header_email_link' masterpage='globalstwo.php'/>" >
    <i class="bx bx-envelope"></i>
    Email: <cms:get_custom_field 'header_email_link' masterpage='globalstwo.php'/>
</cms:cloak_email>

Simple and efficient?

Yeah think that would work that way trendoman, thank you appreciate it

Hi,

I have some customer, who edit text in ckeditor. Sometimes they forget, that they are not allowed to set a mail link. This destroys the output. Can we extend the email guardian to recognize the a-Tag with and change email addresses in the href?

Greetings
Bertram

Hi Bertram. You bring up a good point. I've had that exact same thing happen to me. Like I said to Ian, this tag has very modest ambitions. It's a simple tag with a narrow focus. It was intended to simply protect a user who wouldn't think twice about dropping an email into a block of text.

It seems like a natural extension of this tag to also cover mailto links. But functionally it is a very different and more complex task to find, parse out, and obfuscate complete anchor tags with a mailto link. I don't currently have anything in my back pocket to be able to add this functionality. I'll let you know if I come up with something.

I updated the Email Guardian tag to work properly with mailto links. This new tag is much more robust and is meant to serve as a complete, no-fuss solution for protecting email addresses whether they are hard coded by the designer or entered through the admin panel, links or plain text. It encodes the entire <a> tag and won't interfere with query parameters for setting the subject, body message, cc, etc.

The tag is now de-coupled from the cms:cloak_email tag. All plain text email addresses and mailto links inside the tag are obfuscated using a cipher, then decoded with a JavaScript routine to hide them from spambots while displaying them normally on the page.

Usage is just like the original. Wrap any code in the tag to find and obfuscate email addresses. If you're already using the old tag, you can replace it with this one without changing anything else.

Code: Select all

<cms:email_guardian>
    <cms:show my_blog_post>
</cms:email_guardian>

There are two new parameters for customizing behavior:

no_script_message - In cases where Javascript is disabled, this message will be displayed instead of the expected content. The default is no_script_message="Please enable JavaScript to see this email address."
create_links - For free floating plaintext email addresses, the Email Guardian helpfully converts the address to a clickable mailto link. To turn off this feature and simply obfuscate text email addresses without converting them, set create_links="0".

I'll drop this updated add-on right here for a little while so beta testers can poke at it before I post it at the top of the thread. Please let me know if you have any problems or suggestions.

Edit: Thanks to those who tried the file or offered feedback. I removed the zip to work on it some more.

I'm feeling pretty good about the new email_guardian tag now, so I've uploaded the zip file to the first post of this thread. (viewtopic.php?f=8&t=11001#p28335)

The new tag handles emails, mailto links, non-latin and non-standard email addresses, and complex syntax in mailto tags. The final output on the page leaves your original code unaffected by conversion artifacts, so you shouldn't have to jump through hoops to get styles or dynamic scripting to work properly. For instance, the code that Ian asked about earlier can be wrapped in the email_guardian tag and come out obfuscated but unchanged, so the envelope icon will be inserted as expected without monkeying around in the stylesheet.

Code: Select all

<cms:email_guardian>
<a href="mailto:email@domain.co.uk">
<i class="bx bx-envelope"></i>
Email: email@domain.co.uk
</a>
</cms:email_guardian>

There's one strange issue that I can't figure out. The regex can identify email addresses with non-latin characters, whether they are German or Chinese, but for some reason that I can't understand it's blind to Hindi. Maybe someone on the forum can help me figure out the problem.

I've attached a test template below for anyone who wants to try it out, try to break it, or work on the Hindi problem. I think this new tag is a big improvement over our current tools for obfuscating email addresses. I hope it will be a valuable resource for the community.