How To Encode Your Email Address In WordPress Posts/Pages (No More Spam?)

How To Encode Your Email Address In WordPress Posts/Pages (No More Spam?)Most of you will know that it is generally a bad idea to include your email address on your website. It is likely to get picked up by a spambot; and once it is in the hands of a spammer, you’re going to have a whole lot (more) crap hitting your inbox.

Back in February, Joe wrote an article showing how you can encode your email address in WordPress. He demonstrated how you can manually insert PHP code into your theme’s template files so that spambots see this kind of gobbledegook:

Encoded Email
Joe also mentioned a few plugins that allow you to encode email addresses from within posts and pages.

But as you may know, I am not a fan of using plugins when it is not strictly necessary (and especially if you can achieve the same result with a simple shortcode).

Which is why this short post over at bavotasan.com caught my eye. Mr. Bavota created this simple shortcode:

1
2
3
4
5
// EMAIL ENCODE SHORTCODE
function email_encode_function( $atts, $content ){
return '<a href="'.antispambot(">'.antispambot($content).'</a>';
}
add_shortcode( 'email', 'email_encode_function' );

Once you have implemented this code on your site, you can encode an email address in any post or page on your site by simply wrapping it with the appropriate tag:

1
[email][email protected][/email]

Simple! If you’re organized with your shortcodes, you’ll have created a plugin which houses your entire collection (keeping your custom shortcodes separated from your theme files is highly recommended). If not, doing so is a piece of cake.

The Bigger Picture

In Joe’s post that I mentioned earlier, Shawn K. Hall (regular WPMU reader) put forward the argument that WordPress’ antispambot() function (upon which the above shortcode is based) is essentially useless. The most basic form of this argument would be that if something can be encoded, it can be decoded. If a spammer collects a list of email addresses that have all been encoded in the same manner, it would theoretically not take long to decode them in bulk.

Now I would be the first to admit that I don’t know understand a spammer’s methods, but even if WordPress’ function is ineffective in terms of protecting email addresses, would a spammer want to go to the trouble of decoding a few encoded email addresses amongst hundreds or thousands of unencoded email addresses, or would he/she just discard them?

But there is a more salient point – if WordPress’ antispambot() function is in fact completely ineffective, why on earth is it part of the WordPress source code? I welcome your comments below!

Creative Commons image courtesy of dok1

Comments (14)

  1. Just wanted to comment on something you said…

    “But as you may know, I am not a fan of using plugins when it is not strictly necessary (and especially if you can achieve the same result with a simple shortcode).”

    You do realize that this statement is pretty silly, right? Adding code to create a shortcode into your themes functions.php file is really no different than installing and activating a plugin that does the same thing. In fact, i’d argue that it’s the wrong way to handle it.

    You basically said “Why install a plugin when you can just add the code the plugin would do directly into your theme.”, Ultimately the code is going to get executed. Placing it into your themes functions file vs. activating a plugin that does the same thing is not going to perform any better.

    The type of functionality outlined in this post, protecting and encoding emails in WordPress Post and Page content, should be done by wrapping the shortcode functionality as a plugin that you then activate on the site.

    Why? Easy. A plugin will still be there no matter what theme you are using. If you implement this functionality in your themes functions.php file and then down the road you switch themes and have forgotten about this functionality… the shortcode you have implemented is no longer going to work.

    When you implement this functionality as a plugin it will be theme agnostic and will be more reliable and future proof going forward.

    Something a lot of smart developers do when handling small code snippets of functionality such as this is they DON’T place it in the theme. They create their own custom plugin that they use to house their preferred code snippets. This way it is not tied to any one theme and they can centrally manage their custom code implementations by editing a single plugin.

    • Wow, Carl, buddy…I had to go back and re-read the article to check that I wasn’t going mad, but you really should read things properly before you start accusing people of silliness :-)

      My statement wasn’t silly – although I praise you for using such a relatively lighthearted word and not resorting to more incendiary name-calling.

      The functions.php file is mentioned three times on this page…all in your comment. On the contrary, I clearly recommend that the shortcode should be placed in a plugin of your own design – preferably a plugin that houses a collection of your own shortcodes.

      Why? Because 1 plugin containing 10 specific shortcodes is far more efficient than installing 10 plugins all doing different things (and likely including extra functionality that you don’t even need).

      ‘You basically said “Why install a plugin when you can just add the code the plugin would do directly into your theme.”’ No I didn’t Carl. I didn’t even get close to saying that. If you read the article properly you will actually see that I recommend using a very simple shortcode, which you should put into your own plugin. I even go as far as to specifically state, “keeping your custom shortcodes separated from your theme files is highly recommended”.

      I find it rather bemusing that you spent time in your comment trying to deliver a message that had already been clearly delivered in the article itself.

      Silly Carl :-)

Participate