Recommended method for email obfuscation?

Hey @gauss256!

There is a way to obfuscate the email addresses directly in WordPress core. Will the answer posted here work for you as well?

https://theeventscalendar.com/support/forums/topic/email-obfuscation-in-single-event-view-with-email-address-encoder/#dl_post-957241

Cheers!
Geoff

Were you aware that, if you obfuscate an email address, you render it completely unusable/unreadable for some visitors?

That’s a solid point!

@geoffgraham: The built-in antispambot technique was shown in 2008 to be pretty weak. No doubt the spambots have gotten even better since then.

@esmi: It depends how you do the obfuscation. If you can copy the address from the page, it would be OK for most users, wouldn’t it?

For now, rather than use antispambot, I’ve implemented the “display:none” technique

$eparts = explode("@", $email);
$ename = $eparts[0];
$ehost = $eparts[1];
return $ename . '<span style="display:none">do not harvest me</span>@' . $ehost;

This also requires me to defeat the esc_html( $email ) in organizer.php.

If you can copy the address from the page, it would be OK for most users, wouldn’t it?

Not necessarily. I’m thinking of visually impaired visitors using a screen reader. What the reader doesn’t “parse”, they can’t copy. Ditto for those using voice control software. Not even sure how a switch user would cope with this.

Bottom line is that not everyone uses a mouse and/or a graphical browser.

I get it. I really do. No one wants to get hit by a ton of spam because they have their email address on a web site. But, bottom line, as a site owner, I feel it’s better to maximise contact with visitors and investigate steps to minimise the negative effects on my inbox than to potentially create barriers for visitors so I can have a nice clear inbox.

There’s always contact forms as an alternative. With a little thought, they can still be accessible to everyone.

I just tried the screen reader ChromeVox on the solution I described above. It was able to read the address correctly.

I agree that the visually impaired need to be accommodated. But if screen readers work and copy-and-paste works, it seems like we have the best of all worlds.

The current wisdom is actually that you should just give up on protecting email addresses from harvesters and trap spam at the email client level. (Gmail, for example, does a fine job.)

But in my case the client is paranoid about spambots so I’m trying to satisfy them while keeping the site as usable as possible for everyone. I’m just wishing I could get a little more flexibility from Tribe to do so.

Thanks for sharing your feedback, use case, and results.

Is there anything more we can do for you on this topic?

Is there anything more we can do for you on this topic?

My current solution is not very good. I’d really like to know if there is a way to use JavaScript to display the organizer’s email.

And if not, I’d like to put that forward as a feature request to the dev team.

Here is a more specific question/request. If I edit the file .../src/Tribe/JSON_LD/Abstract.php and comment out the code

if ( ! empty( $data ) ) {
    $html[] = '<script type="application/ld+json">';
    $html[] = str_replace( '\/', '/', json_encode( $data ) );
    $html[] = '</script>';
}

then I can continue to use JavaScript as I have in the past.

My question is: is there any harm in commenting out that code? It puts HTML into the page that doesn’t seem to get used anywhere.

And if there is no harm in commenting it out, could that code just be omitted in future releases?

I’m always a little leery of making changes to core files. I wonder if removing the markup with a snippet like this would be a more maintainable route:

add_filter( 'tribe_json_ld_markup', '__return_empty_string' );

Geoff

I’m always a little leery of making changes to core files.

Yeah, I hated doing that. Your suggestion is much better. Thanks!

Glad to hear you’ve got a workable solution on your hands here! Let us know if there’s anything else we can assist with–thanks much! ??