[Plugin: emObA – Email Obfuscator Advanced] emOba – website hyperlinks disappear !

This is fixed in the development version. Will release as stable 1.6 in a few days. Thanks for pointing it out — I am amazed it never showed up in my use! (I had only partly taken care of regex greediness.)

Thanks – look forward to the update!

In case you want to fix this problem before the next version comes out, I’ve implemented a one-character fix on my local copy of version 1.5.1 of the plugin. If you add a ‘U’ character at the end of one of the regular expression statements, it fixes the problem described here.

Line 152 of emoba.php in the plugin’s folder should be changed to:

'!<a(?:.*)href="mailto:' .EMAIL. '([?][^"]*)?"[^>]*>(.+)!iU',

It originally is:

'!<a(?:.*)href="mailto:' .EMAIL. '([?][^"]*)?"[^>]*>(.+)!i',

The U must be uppercase.

Jonathan

The new version, 1.6, is up now, finally.

@nickstrong: I apologize for not posting the correction with my reply several weeks ago, and for the subsequent delay in updating.

@luckyduck288: Thanks for posting a fix. I chose a more specific guard against greediness. (I don’t like U; it flips the meaning of ?’s within from ungreedy to greedy, which is confusing to me.)

Thanks for posting an update. Version 1.6 breaks emails with ?subject= addons, though, in my install (WP 3.0.1). I get links with weird markup showing in the links. I’ve gone back to my ‘U’ fix for the time being so I can’t post a specific example here, unfortunately.

Jonathan

@luckyduck288 — Jonathan, I don’t see a problem. I just tried
<a href="mailto:[email protected]?subject=whatever is the matter">email</a>
both alone and in a paragraph with non-email anchors, and it looks fine.

Please try again. If it gives problems, please post more detail. Thanks.
Kim Kirkpatrick

Hi Kim,

On further investigation I have discovered the problem isn’t the subject issue. It is actually when there are other attributes on the <a> tag before the href attribute. For example, <a rel="external" href="mailto:[email protected]">Email Me!</a> would cause a problem. As far as I can tell, there is nothing in the HTML spec that dictates the order of the attributes, but I am far from an expert.

Jonathan

@luckyduck288:

If there are other attributes, they will be moved by the WordPress visual editor to the front, before the href, where they will cause the trouble you’ve seen.

To get around this, on line 152 of emoba.php replace (?:[\s]| )* with (?:.*) The result will be as if those attributes were never present; they will not be carried into the obfuscated link.

I will look into manipulating the DOM so these attributes can be saved. Stay tuned.

Wow, thanks for the quick response! This is a really great plugin. Keep up the excellent work.

Wait, maybe I’m missing something, but I actually tried that last fix and that seems to bring back the original problem described in this thread. Am I doing the change correctly?

Please post (between backquotes) a sample that doesn’t work. And also between backticks, the line you changed. Thanks. Kim

I changed line 152 of emoba.php from:

'!<a(?:[\s]|&nbsp;)*href="mailto:' .EMAIL. '([?][^"]*)?"[^>]*>([^<]*)</a>!i',

to

'!<a(?:.*)href="mailto:' .EMAIL. '([?][^"]*)?"[^>]*>([^<]*)</a>!i',

When I try to use the following code in my page:

To contact us <a name="anchor" href="mailto:[email protected]">email me</a> or <a name="anchor2" href="mailto:[email protected]">email me too</a>.

I get the following page output.

To contact us email me too . The email me too is a link to [email protected]. There is no name attribute in the final markup. This is not the end of the world if that is how it has to work. I just don’t want the email links to break.

It should be
(?:[^>]*?)
This works for several links in a row followed by several emails in a row followed by link followed by email. So I think I have the greediness under control, finally.

Sorry for all the confusion; I tried too quick a quick fix for your problem.

The difficulty remains that the attributes are simply removed from the result. I will consider modifying this to find class= and style= and put them back in. But not today. I think this problem is not serious enough (I haven’t heard a complaint before this, although it is a legitimate complaint) to put out a bug fix right now.

Kim

Wow, thank you so so much. It works perfectly!

1.6.5 posted. Handles class and style attributes.