Josh

Hi @kurros,

Apologies for the long delay. We’ve just checked the privacy policy page on your site and ran it through our checker, it looks fully protected now, no unprotected email addresses are visible in the page source.

If you’re still seeing the issue at your end, could you send through:

• The output of “Copy Support Info” from the plugin’s settings sidebar
• Where exactly you’re seeing the unprotected email (a screenshot or the specific line on the page)

Otherwise, sounds like an intervening update has resolved it.

Thanks, Josh

Hi @mastflow ,

Thanks for the extra detail, that really helped narrow this down.

We just released version 2.4.8, which includes a fix we believe should resolve the random characters you are seeing. In short: when “best method (JavaScript disabled)” is active, the plugin inserts hidden decoy text between the parts of an email address. Those decoys are normally hidden by the plugin’s stylesheet, but with some page builder and caching combinations (Elementor Pro included) the stylesheet doesn’t always get applied, and the decoys become visible. The fix makes the hiding work even if the stylesheet never loads.

Could you update to 2.4.8 and check whether the affected addresses look correct now?

If you still see random characters, would you be able to send a view-source HTML snippet of one affected email? You can replace the real address letters with x’s we just need to see the surrounding markup.

Thanks, Josh

Hi @tkendrickweb, @stephenturner, and @rmerz,

Thanks for sticking with us on this one.

We just shipped 2.4.8, which should fix the mailto scrambling inside Divi modules.

The email itself is still obfuscated against scrapers, we just stopped it from chewing up the formatting around it.

Could you update to 2.4.8 and let us know it’s looking right on your end? If anyone’s still seeing oddities, drop a screenshot or a snippet of the source and we’ll dig in further.

Thanks, Josh

Hi @benny54 ,

Sorry for the delayed reply, we shuffled the dev team.

First off, are you still seeing this issue on recent versions of the plugin (latest is 2.4.7)?

If it’s still happening, we’ll need a few things from you to track it down properly – we’ve been through the plugin code and can’t see anything on our side that should interfere with the bulk update process, so this is almost certainly an interaction with something else in your setup:

1. On the plugin’s settings page, click the “Copy Support Info” button and paste the result here.
2. Debug log from a failing bulk update. Add these lines to wp-config.php (above /* That’s all, stop editing */):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce the hang, then send us wp-content/debug.log (and your host’s PHP error log if you can grab that too).

Thanks for bearing with us.

Hi jayti,

Thanks for reporting this, I can see the issue on your contact page. The email addresses are
showing as JavaScript code instead of being decoded.

What’s happening is something on your site is stripping the tags that the plugin uses to
decode emails, which leaves the raw code visible as text. This is usually caused by a caching
plugin, security plugin, or your hosting provider’s firewall rules.

To help me narrow it down, could you go to Settings > Email Encoder in your WordPress admin,
and in the sidebar on the right you’ll see a “Copy Support Info” link with a clipboard icon.
Click that, then paste the result into your reply here – it’ll give me your settings and
active plugins so I can pinpoint the conflict.

In the meantime, a quick workaround: on the same settings page, try changing “Protect emails
using” to “automatically the best method (excluding javascript)” and save. That’ll switch to
a CSS-based method that doesn’t rely on script tags.