Plugin: MD Spam Me Not, alternative to using {encode} for hiding or masking email addresses

This is a bummer as I am a huge fan of the Textile plugin. I don’t think I’ve ever come across putting the spammenot plugin code in a Textile post, though. I think we’re sort of at the mercy of how the Textile plugin parses it’s material.

The only other thing I can think to try is wrapping the spammenot code in notextile tags, which I think are double equal signs.

=={exp:spammenot email="user@domain.com"}==

Then the plugin might not parse at all, though.

The only other thing I can think to try is wrapping the spammenot code in notextile tags, which I think are double equal signs.

=={exp:spammenot email="user@domain.com"}==

Surprisingly, wrapping the SpamMeNot code in double equal signs (==) allows the plugin to work with Textile! It appears this syntax is a valid work-a-round; perhaps you could add this case into the plugins’ documentation so other people could benefit from it?

Also, I noticed that the SpamMeNot plugin isn’t listed in the ExpressionEngine Add-On Library — do you have any thoughts of adding it into directory?

I am really happy that actually works. Thanks for reporting back here, too, as a lot of times once people get something to work they don’t come back to share what actually worked!

You know, I’ve always been too lazy or something to actually add anything I’ve done to the Add-On Library. Maybe I should change that, especially if it will help someone find a plugin quicker.

You know, I’ve always been too lazy or something to actually add anything I’ve done to the Add-On Library. Maybe I should change that, especially if it will help someone find a plugin quicker.

Definitely! I’d be happy to submit your plugin for you if you’d like (it has been quite useful for me and a great alternative to the Hivelogic Enkoder).

The only other thing I can think to try is wrapping the spammenot code in notextile tags, which I think are double equal signs.

=={exp:spammenot email="user@domain.com"}==

Then the plugin might not parse at all, though.

This is not working for me. But after some testing, I don’t think Spam Me Not is being invoked at all, with or without Textile. I’ve uploaded 1.03 to the plugins directory. It shows up in Plugins Manager. Is there something else I need to do?

And are you guys invoking Textile manually by using the Textile tag in your templates themselves, or are you setting your custom fields to “Textile”?

There should be nothing to do other than uploading the plugin. You’re using Textile tags on your template, rather then setting the field to Textile, and it’s not working? I’m always invoking Textile by setting the custom field to Textile, and I’m assuming Ryan Bonnell is doing the same.

You can’t just put this on a template, outside of any entries tags for simplicity, and have it work?

This is not working for me. But after some testing, I don’t think Spam Me Not is being invoked at all, with or without Textile. […] Is there something else I need to do?

In order for the SpamMeNot code to work in an entry, you need to install the Allow EE Code plugin, since ExpressionEngine tags are not permitted by default with an entry.

And are you guys invoking Textile manually by using the Textile tag in your templates themselves, or are you setting your custom fields to “Textile”?

I’ve done it both ways (Textile specified in the template, or manually in the entry), but I prefer to have Textile selected as the formatting type within the entry so that any changes to an entry’s markup don’t require editing templates.

Note: The big benefit of specifying the formatting type with an entry is that each field is able to use a different formatting. For example, Summary could use XHTML, Body could use Textile, while Extended could use Markdown with SmartyPants and ExpressionEngine is smart enough to output everything individually using the formatting type you specified!

You can see how I am using the SpamMeNot code in conjunction with an entry in the attached screenshot (the mode=”2” simply changes the output from decimal to hexadecimal and shouldn’t affect whether or not the plugin works).

Thanks to both of you for the speedy responses.

I found the problem. I was using a newer version of the Textile plug-in than the one in the Add-Ons library. I was doing this to try to solve some other Textile problem I was having. Somewhere in these Forums (I don’t have it bookmarked), somebody updated Textile and I was using that one.

The Textile plug-in PHP files have version lines in them:

I was using this version of the Textile plug-in and it did not work with Spam Me Not 1.0.3: $LastChangedRevision: 2670 $

I fell back to this version of the Textile plug-in and Spam Me Not now works: $LastChangedRevision: 2462 $

I added a quick snippet to help the link validate when using the subject line with spaces.

Line 62:

$subjectEncoded = rawurlencode($subject);

and the change line 83:

if($subject != '') $subject_line = "?subject=$subjectEncoded";

I’m no PHP programmer, so I’m not sure if this is the most elegant fix, but it works like a charm. I’m pulling in {title} data from a weblog entry to serve as the subject line of the email, so I needed the spaces to convert to entities in order for the link to validate.

Hey Ryan,

I have been using this plugin for a while now and I love it! I am running into an issue when I try to pass the plugin a custom field for the email parameter. For example, if I was in the weblog:entries tag and I did this:

{exp:md_spam_me_not email="{resume_email}" mode="1" title="Email Resume for this Job" subject="Resume for {title}" text="Email Resume »"}

It seems to allow the weblog fields in the subject but for some reason it breaks when I use it in the email parameter. Is this a bug or am I doing something wrong?

Thanks

Michael

Have you tried using the parse=”inward” parameter on your weblog:entries tag?