ljmac

I’m having this CSS clear issue as well – hopefully this will be fixed in the version Mark is about to release!

It doesn’t seem to cause any problems, but of course if you could come up with a more elegant and flexible solution that would be even better!

Still, would your solution require and update to Bad Behavior, or will it continue to work as it is?

I have to add a crucial new piece of information here: I am now using Bad Behavior as well! I did this because some hacker hit my database so hard that it got knocked out. Looking at my logs, it appears as though they had some kind of exploit specifically tuned to WordPress blogs – I must have gotten over a hundred queries per second, which naturally sent MySQL haywire. So far, since installing Bad Behavior it hasn’t happened again. Also, it keeps very good logs of everything it does, and there don’t appear to be any false positives either. Having to modify WP-SuperCache is annoying, but not too difficult – I wish Donncha would add it to his code!

Oh yes – one other way to block spam at the door is to use Donncha’s .htaccess rules for Cookies for Comments:

For the adventurous, add these lines to your .htaccess and it will block spam attempts before they ever get to WordPress. Replace the Xs with the cookie that was set in your browser after viewing your blog. Make sure the lines go above the standard WordPress rules.

RewriteCond %{HTTP_COOKIE} !^.*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.*$
RewriteRule ^wp-comments-post.php - [F,L]

However, this means that any users without cookies enabled will get their comments deleted without any warning whatsoever. Also, I personally have not been able to get this working on my server, and I still don’t know why (perhaps it is a conflict with Ask Apache’s .htaccess rules).

The reasons the tests are failing are probably due to permissions and such – as I said, using Ask Apache requires a fair bit of technical knowledge (and server access) unfortunately. If you do get it working, do NOT enable the following modules:

Protect WP-Content (breaks many plug-ins)

Specify Characters (this will break your site depending on what permalinks you use, such as the most popular date based format)

I also recommend not enabling the Forbid Proxies module, as it will prevent a small percentage of legitimate users from posting. The rest appear to be safe to use in my testing.

Also, if you use permalinks and/or WP-SuperCache (or any custom .htaccess rules), I recommend re-setting their .htaccess rules AFTER setting up Ask Apache, as it may erase other directives in your .htaccess file during installation. As I said, this plug-in is pretty dangerous, so you really need to know what you’re doing!

The other big problem with WP-Spamfree is that it occasionally blocks legitimate comments, and unfortunately the author seems unwilling to recognise the problem, let alone do anything about it. I would like the option of switching off the algorithmic layer, as I believe this is what causes the problems – I really think that moderation is the only way to deal with human spam without false positives, and the JavaScript/Cookie layers already completely block bots.

Anyway, I started another thread on this issue, which has lots of good discussion about the pros and cons of the various alternatives to WP-Spamfree – you should be able to find an anti-spam solution that works well for you by going through the comments there:

https://www.ads-software.com/support/topic/214198

I think the best way to block bad bots at the door without blocking good ones is AskApache Password Protect, which I also use. It uses tried and tested mod_rewrite rules to block bad bots, without blocking legitimate users (some modules have the potential to do this, but you can switch them on and off as you see fit). Indeed, it is so effective that so far no spam has gotten past it on my site at all (Cookies for Comments and WP Hashcash are actually just backup measures, which haven’t been required so far).

HOWEVER, this plug-in does some serious stuff that could completely break your site – if you don’t know your way around .htaccess on your server, then it’s best to stear clear of it I think.

The issue with WP-Spamfree is not due to its use of JavaScript as such, but due to its complexity – particularly the algorithmic layer, which is what results in false positives. WP-Hashcash is much simpler – if the user has JavaScript enabled, it will work. It also has the same functionality as simple-trackback-validation to block malicious trackbacks/pingbacks.

Of course, the greater simplicity in theory means it could let more spam through than WP-Spamfree, but in combination with Cookies for Comments, you have two layers of protection, which no bot will get through. And there really don’t seem to be ANY false positives (and even if there were, you can set it to moderate anyway). Even better, if the user has JavaScript disabled, Hashcash gives them a warning BEFORE they post.

Regarding Bad Behaviour, it requires modifications to WP-SuperCache (which makes me uncomfortable) and it does have the occasional false positive (which makes me even more uncomfortable). It is algorithmic, so in theory it has the same succeptibility to false postives as WP-Spamfree does (if not more so).

Actually Donncha, I just thought of something that could solve my problem, and make life a lot easier for everyone: why not add an option to CFC to add the right htaccess code automatically, just as WP-SuperCache does for example?

With all due respect WebGeek, you seem very quick to place the blame elsewhere when something might be wrong with WP-Spamfree. People here have stated repeatedly that switching on WP-Spamfree blocks pingbacks, and switching it off allows them to work again. What if the latest version of the plug-in is inadvertantly switching on “block pingbacks” all the time, regardless of how the user sets it? This is an obvious possibility, but you haven’t even investigated it.

Also, I opened a thread three weeks ago – and sent you a support email as well – about WP-Spamfree blocking legitimate comments at the blog I run. I came up with a couple of feature requests that could possibly solve this problem, but you haven’t responded at all.

Anyway, I’ve made the switch to Cookies for Comments and WP Hashcash, which combines cookies and Javascript as your plug-in does, but with far greater compatibility and (unlike WP-Spamfree) no false positives. And also unlike Spamfree, you can set them to moderate, so even if there are false positives, you can catch them anyway. With WP-Spamfree, you can never know if it’s blocking legitimate comments unless your readers complain (as mine have) or you happen to catch it out (as I have a well).

Cookies for Comments is here:

https://ocaoimh.ie/cookies-for-comments/

WP-HashCash is here:

https://wordpress-plugins.feifei.us/hashcash/

Together, they effectively replicate the automated spam blocking of WP-Spamfree, but WITHOUT false positives (WP-HashCash also blocks automated trackback/pingback spam). As long as a human commenter has cookies and JavaScript enabled, they will be able to comment.

They are also fully compatible with WP-SuperCache (Donncha authored all three plug-ins), and do not require any special modifications to your templates etc. They are also far more compatible with other plug-ins than WP-Spamfree (I had a lot of compatibility issues with WP-Spamfree, but have had none with these two plug-ins).

My blog resides in the subdirectory “english” – how would I modify it to point directly to my WordPress directory? I tried the obvious /english/wp-comments.php but that didn’t work either.

I assume I must have the cookie code correct, otherwise I can only imagine no one would be able to comment!

The only other possibilty I can see is some kind of conflict with AskApache Password Protect’s rewrite rules (these are placed after the WordPress rewrite rules by that plug-in).

Hi donncha,

That’s exactly where it is, as per your instructions (before the WordPress rewrite rules, right?).

Perhaps I am misunderstanding the way it works. I was expecting to see nothing of spam blocked by .htaccess. Is my assumption correct, or does it still get recorded as spam if I have CFC set to “Spam”?

First of all, apologies for the spelling errors in the subject line of my post! Secondly, as it seems the author of WP-Spamfree is unavailable, I’ve decided to do my own custom contact form (fortunately I have the knowledge to do this), and switch to Cookies for Comments and WP Hashcash. Together, they largely duplicate the automated spam blocking of WP-Spamfree (and also block trackback/pingback spam), without blocking human comments (only moderation can do this without false positives IMHO). And in the unlikely event that these plug-ins generate false positives (so far they seem absolutley bullet proof), they can send them to the moderation queue instead of just blocking them as WP-Spamfree always does (so you can never know if there are false positives, unless you catch it out yourself, or your readers complain).

I’ve decided to stick with 3.5.9 too, for exactly the reasons you describe. It is one of those rare pieces of software that does everything I want it to, but nothing more – and in a simple, elegant way. It’s a shame this version will no longer be maintained for future versions of WordPress.

I also had the same problem with 4.5+ version of Ask Apache Password Protect – he made it more complex, which also made it cause more problems (every time I try the newer versions, it wipes out all my .htaccess settings, which completely breaks permalinks and other things). So I’ve stuck with the old version (4.3.2), which was simple, elegant, and did everything I wanted it to.

To stop the upgrade notices, I simply modified the version numbers at the top of the plug-ins’ php files. If you want future upgrade notifications, set it to the current version number. If you never want notifications, set it to a “future” version number.