Update 7/31/2013—The following review is of an older version of the plugin. As of the newer 2.0 branch, many of the issues below have been resolved.
A friend of mine directed me to a new spam fighting plugin via a retweet today.
I'm always on the lookout for cool new software, and as I highly respect my friend's opinion, I had to take a look. Two things about the plugin download page immediately raised some red flags, so I wrote the plugin off and said so on Twitter. The immediate response: that I was too quick to judge.
So here's my full review of the plugin.
Refreshingly, the plugin itself is licensed under version 3 of the GPL (which is a requirement to live in the WordPress.org repository). However, there is a somewhat confusing IP disclaimer at the top of the plugin file:
Intellectual Property rights reserved by Todd Lahman, LLC as allowed by law incude, but are not limited to, the working concept, function, and behavior of this plugin, the logical code structure and expression as written. All WordPress functions, objects, and related items, remain the property of WordPress under GPLv2 (or later), and any WordPress core functions and objects in this plugin operate under the GPLv2 (or later) license.
While I am not a lawyer, this doesn't appear to me to violate the GPL, as the GPL still requires a copyright notice to accompany any re-release of licensed software. It does, however, go above and beyond what is normally seen in plugins.
The readme file is what threw up my original red flags.
First of all, the plugin makes some truly interesting claims:
- Automatically blocks 100% of automated comment spam
- Local IP address blocklist for manual spam
- Almost zero database load under the heaviest spam conditions.
- Zero false positives
I use Akismet for most of my sites - which is also free. Akismet uses algorithms that help it automatically learn from its mistake, meaning every false-positive (or false-negative) helps to make the system smarter. Also, it runs on WordPress.com, meaning there are literally millions of data points available to help refine the spam catching system.
But even Akismet can't guarantee 100% efficacy. Nor can Akismet claim zero false-positives.
In my experience, when something sounds too good to be true, it probably is.
The more outrageous claim, though, is that the plugin has been tested up to WordPress 3.7. For those keeping score at home, at the time of this writing, WordPress 3.6 is still in beta and 3.7 hasn't even been scoped for development yet.
While the plugin might overstate its compatibility with WordPress, it does go to great lengths to be compatible with everything else on your site. The plugin disables certain additions by Jetpack that override your comments. It also has hooks set up for several major themes' comment areas so there's a minimal amount of configuration needed on your part.
A cursory glance at the codebase shows explicit support for:
If you're a native English speaker, and your WordPress backend is in English, then you won't notice any problems. If, on the other hand, you administer your site in a language other than English (or want to use this plugin on a non-English client site), then you'll be in for a surprise.
The plugin itself advertises language support for:
- German - (de_DE)
- Italian (it_IT)
- French - fr_FR)
- Hebrew - (he_IL)
- Japanese - (ja)
- Chinese - (zh_CN)
- Hong Kong - (zh_HK)
- Taiwan - (zh_TW)
- Swedish - Svenska (sv_SE)
- Norwegian - (norsk)
While these translations exist, and a large portion of the codebase uses WordPress' built-in translation functions, a significant amount of UI code does not.
For example, certain parts of error messages are translated while others are not. Let's say someone with a blocked IP address submits a comment. They will see an error message in the site's I18N language equivalent to "Comment blocked by Spam Free WordPress because your IP address is in the local blocklist, or you forgot to type a comment."
But the title of the error page - "Spam Blocked by Spam Free WordPress local blocklist" - will not be translated.
Certain options on the plugin's settings pages are also not translated, as are portions of the plugin's built-in comments template. This is an oversight that will affect both the back end and the front-end.
The plugin makes fantastic use of nonces to secure its various actions.
When direct database calls are used, everything is properly sanitized and escaped. The funny thing, is that even hard-coded data is being run through $wpdb->prepare, which is unnecessary. This is probably a holdover from some version of user input, though, and it doesn't cause any issues.
This is the biggest bone I have to pick with the plugin. Huge swaths of functionality are disabled unless you enter an API key. This includes:
- The local spam IP blocklist
- The option to customize the comment form message
- Local cron jobs to clean the database
None of these features requires a remote connection, but they're crippled in the plugin unless you validate an API key against the author's server. For the record, this is explicitly against the WordPress.org repository guidelines:
All code hosted by WordPress.org servers must be free and fully-functional.
The only part of the plugin that requires remote access is the part that actually validates the API key. Comments are not validated against an external API or blocklist at all, and no web services are involved to enhance the functionality of the plugin.
This is not a plugin I could ever recommend using on your site.
If you already have it installed and love the functionality, feel free to keep on trucking. But the fact that the plugin requires you dial in to an external server for no other reason than the author wants to know who installed the software and where is an even bigger flag in my book than overstated efficacy or overconfident compatibility claims.
With this said, what do you look for in a plugin as a solid go-nogo for making a recommendation? What other features would you like to see covered in a review before making a decision one way or the other?