alexanderbailey
Forum Replies Created
-
You beat me to it! 😉
I was waiting on a clone/migration to complete so I could test commenting out the cmplz_document_email function as your message came in.
It looks like the source of the problem is a standard WP function, antispambot(), which the Complianz team is relying on to provide useful obfuscation.
It’s a little off-topic, but there’s an interesting comment by user Nazrinn on the antispambot() page.
I’m also discussing this with another Email Encoder user in that plugin’s support forum here: https://wordpress.org/support/topic/html-entities-will-be-overlooked-by-email-encoder/
A cheap workaround (inspired by a reply in the other forum) would be to add an advanced setting/preference to Complianz to disable Complianz’s default email obfuscation treatment.
I like how you are thinking.
On the good news side, Complianz’s dev team will at least be evaluating my suggestion (https://wordpress.org/support/topic/complianzs-email-address-obfuscation-is-worse-than-nothing/).
Thank you!
If the team wants to continue to provide obfuscation within Complianz, I’m a fan of this page on the topic. When hand-coding sites I usually use a version of the CSS Display None method that I strengthen by using an nth-of-type selector so that it isn’t obvious which bits of the email string need to be stripped out. (I’m happy to spell this out in detail off-forum.)
Email Encoder’s treatment is more complicated, employing javascript encoding and CSS text direction to scramble and unscramble addresses for bots and humans.
I thought about removing a few characters from the beginning of the email address when entering it in Complianz and then adding the missing characters via CSS, for example, truncate “contact” to “ct” and use .cmplz-contact-email::before { content: “conta”;}. However, while the email address will then display as desired on the webpage, the content restored via CSS won’t be user-selectable.
Whoops! I just noticed that the example of Complianz’s HTML output that I gave above lost its HTML-entity-encoding. (Did I get sloppy and copy the code from Chrome’s inspector after editing the email address? Or did the code block here decode the entities?)
Let’s try that again:
<span class="cmplz-contact-email">cntact@ark.com</span>Here’s a screenshot of the code by way of backup:
Confirmed. The plugin works now for standard admin users on our multisite. Thank you, Jens!
Thanks @jekuer! I’ll will keep an eye out for the next release, test, and report back.
We use another plugin, Embed Iframe, to allow standard admin users to add iframes to their content, which would otherwise require super admin capabilities on a multisite. I notice that Embed Iframe doesn’t supply its own block; instead, users enter a shortcode. I think this gets us around the unfiltered_html capability requirement. (Needless to say, a dedicated block is vastly preferable to using the shortcode block.)
I have the feeling this plugin doesn’t work anymore: when I inspect the HTML code of the contact page of my website, I can see the email is not obfuscated anymore.
Your browser’s web inspector will show you the resulting code after javascript has run. That’s why you see a readable email address in your HTML. If you use your browser’s “view source” instead, you will see that your email addresses are, in fact, obfuscated.
All good, thanks for replying. It was my fault for failing to save my SMTP credentials after entering them.
Forum: Plugins
In reply to: [Network Posts Extended] NPE occasionally lists ACF fields in reverse orderYes! It’s fixed. After updating to 7.6.2 and clearing the server’s cache, the order of the fields became consistent. And, what’s more, it’s now writing the ACF-fields in the order used in the shortcode. I can update my CSS to remove the flexbox order reversal. Thank you!
Forum: Plugins
In reply to: [Photo Engine (Media Organizer & Lightroom)] Staging / Site MigrationBrilliant! Thanks Jordy.
Forum: Plugins
In reply to: [Contact Form 7] Anonymizing Remote IP Address: Not WorkingThis is resolved for me.
Forum: Plugins
In reply to: [Contact Form 7] Anonymizing Remote IP Address: Not WorkingI’m happy to report that
wpcf7_anonymize_ip_addr()is working for now. The last chunk of IPv4 addresses is being converted to 0.This is the code I have in my functions.php:
if (function_exists( 'wpcf7_anonymize_ip_addr' )){ add_filter( 'wpcf7_remote_ip_addr', 'wpcf7_anonymize_ip_addr' ); }- This reply was modified 5 years, 7 months ago by alexanderbailey. Reason: Fixed typo in position of closing CODE tag