What you get with this is a customizable (via the back office) plain text field that your visitors will have to fill in before they can leave a comment. Registered bloggers are exempt from the test, as are those who've successfully left a comment already. You will be able to customize the test and answer and rejection text in your back office.

First modify your database. Using something like phpmyadmin add three fields to your settings table:

Further down in the same file do this, and be aware that your skin might use different class names. In fact it might be structured completely differently, so you'll have to keep an eye on the code in the area you're modifying to make sure it looks right when you're done:

EDIT #2: Lotsa changes from the original posting of this. Most notably, and the reason for the second edit, is that this now works with register_globals OFF. The astute reader will find the corrective bit in the edit for htsrv/comment_post.php and will notice that it is pretty much exactly what blueyed said it would need to be. ;)

I don't know about other systems, but I had it in place for most of the time I used the .9 generation and NEVER got comment spam. Back then I didn't add bits to the settings table and therefore couldn't control it through the back office, but the end result was the same: once in your commenting life you were expected to prove you were human.

As to being a plugin: maybe but I sort of doubt it. I have no idea how to add fields to a database table using a plugin, and I don't think there are any hooks inside the various back office tabs. I think when 1.8 comes out it'll be much more possible, but I still won't know how to alter a table upon installation of the plugin.

Thanx Ed, this Turning Test is much more user friendly than a Captcha, though I noticed one little bug with the way your code checks to see whether or not the commenter needs to answer (or even view) the turing test question if they are a registered user and/or regular commenter.

Your hacks to _feedback.php first check (via the "name" cookie) if the commenter has left a previous comment and then you set the variable $comment_test_answer with the test answer if indeed commenter has previously set a "name" cookie.

Then, if the commenter is logged in, you store the $comment_test_answer in a hidden input value, but if they are NOT logged in, then they are prompted to enter the answer manually in a text input.

The problem is, it is possible for a registered user to be logged in but NOT have a cookie stored while making a previous comment (since reg'd users set a "user" cookie instead of a "name" cookie set by commenters) so the hidden form input "is_human" will have a blank value instead of the answer and the commenter will be told that they gave the wrong answer for a question they never saw.

It is also possible for a previous commenter with a successfully stored cookie to still be prompted for the turing test answer again and again because they are NOT logged in (they might not even be a registered user).

My suggestion is to first remove the code that checks whether or not the "name" cookie has been set when setting the variable $comment_test_answer.

Then, instead of putting the form input options (hidden or text) inside their respective pre-existing "is_logged_in()" if / else, i'd recommend adding a separate if / else specifically for the turning test like this:

This checks if the commenter is either logged in OR if they have successfully posted a previous comment and set a cookie. They only see the Turing Test Question if they are not a logged in red'g user nor have the cookie set.

Hey! I noticed the same funky thing, but not until I did the hack for the phoenix alpha release. I came up with the same first-part of your answer, but a different second-part. What I went with to get the registered blogger past the test was to move where I reviewed "is_human" in comment_post.php. There is a big bit of testing that happens only when the visitor is not logged in so I figured there's where it should go.

Cool. So what I'll do is - after a fashion - double-check your method and add it to the original post above after I see that it works like you already know it does.

the settings were:What color is red?redYou have to answer the question in order to prove you're a human. What color is red? Here's a hint: three letter answer.

any ideas?

Two ideas: first check the updated version of the hack. Second try to think up YOUR OWN QUESTION AND ANSWER! I had this hack a long time ago and never shared it because I figured people wouldn't bother to come up with their own text, but finally decided to go ahead and give it a go. I intentionally put nonsense in the initial installation figuring since it won't work people will HAVE TO think up their own stuff, but that didn't work. You copied my question and answer. Duh...

MarcDK wrote:

Works great but as an admin I am not able to post! =(( What should I do?

Check the initial post for two updates to the comment_post.php file. The first fixed this problem by not bothering to test registered bloggers. The second update is something people might need, but it won't affect the 'admin can't comment' problem. It would stop the hack from working for other visitors, and AFAIK it is something about server configuration.

It's not that hard really. Get into your phpmyadmin and on the left you should see a dropdown box where you select the database you want to work on. If you've only got one database then chances are really good it's your b2evolution database. If you've got multiple databases you have to pick the right one. You could download a copy of your conf/_config.php file to see what your database is called, or if you used Fantastico to install b2evolution you just pick the one with "_bvlt" in the name, or just select each database one at a time until you see one that has table names beginning with "evo_".

Once you find and select the right database you should see a list of table names on the left and a "table of tables" on the right - the main section of the screen. Use the bit on the left to select your evo_settings table. The stuff in the main body of the page will now change to focus on that exact table.

Next select the "SQL" tab from the top and you'll get a box with a query automagically filled in. Delete the stuff it puts there then copy the first of the three statements above and paste it in there, then click "go". Repeat for the other two statements above.

BTW once you see the detail of your 'evo_settings' table you can click browse to see all the details of what's in that table. After you've gotten all three statements above executed you can click it again to see that you've done it correctly.

Not that hard, but not super obvious either. Play carefully and give a care to what you click, but I think these instructions should get you through it.

Awesome. Thanks for the response. I'm at work for the rest of the afternoon, unfortunately, and they block my access to the Bluehost panel (probably a good thing anyway). But I'll give it another go later on tonight or tomorrow and get back with any further questions.

I look forward to learning how to make plugins the hard way: by making one!

(When this becomes a 1.8-plugin I will do my best to make it completely compatible with the .9.1 and 1.6 hack versions just so's those who've either used it or try to give it a go won't lose what they've gotten used to having.)

I mean, it works fine if I'm logged in -- don't even get the prompt for it like I'm sure I'm not supposed to. But (since I'm thorough) I tried to comment while logged out and the above is what happened.

Do I understand correctly that you, as admin (actually any logged in member) can't post a comment? I thought I fixed that by making it so that if you were logged in you (a) got credit for knowing the answer and (b) didn't get tested anyway. So if you're logged in and commenting is it showing you the question box? If so is it auto-filling the answer? Either way it is not allowing you to comment?

Otherwise it is possible that you are testing what a non-logged in person sees? Therefore you see the question with an empty answer box and type in the correct answer but it doesn't allow your comment? I thought I had a fix for that as well even though it was not a problem on my server configuration.

Which case do we need to fix? You are logged in and tested, or you are not logged in and not allowed to comment? Oh in both cases, of course, verify in your back office that your question, answer, and reject text are what you want them to be. The answer will be case-sensitive. "Blah" is not "blah".

Which case do we need to fix? You are logged in and tested, or you are not logged in and not allowed to comment? Oh in both cases, of course, verify in your back office that your question, answer, and reject text are what you want them to be. The answer will be case-sensitive. "Blah" is not "blah".

No, it does what it's supposed to if I'm logged in (i.e. doesn't even prompt me to type "human"). It's when I'm logged out that the problem arises and typing in "human," all lower case as it's entered for its database value, still brings up the screen telling me to try again.

So far we know quite a bit. You've got the database modified, and your _feedback.php is asking for the question, but it doesn't like when I type either "canses" (as it tells me to) or "human" as based on your post. You can comment when logged in, so we know (a) that part of the hack is behaving and (b) nothing else got buggered up. So all we have to fix is the bit where a random surfer wants to comment.

Let's look mostly at htsrv/comment_post.php to fix this. There are two changes to this file: one gives your custom error message, and the other supports servers that are different than mine. I see your custom error message (I suspect you are spam, please try again.), so the first part must be okay. Therefore you should verify the second part.

That would go very near the top of htsrv/comment_post.php, and the only actual change is the addition of the "param ishuman" bit.

Oh plus I notice you're using version 0.9.0.11. I did not test this hack with that version so it is possible it will not work for some reason or other. I suggest, even if you get the hack working, that you upgrade to version 0.9.1b. The biggest gain you will see with that upgrade is that your server will work a lot less when it rejects spammers who are listed in your local copy of the antispam database. Alternatively you could wait for the upcoming release of version 0.9.2, but either way you will lose this hack. In both cases only teeny tiny changes to your skin will be desired though not absolutely required.

Yep, I did the two modifications to the htsrv/comment_post.php file as written, but it still won't work for me so I suspect...

EdB wrote:

Oh plus I notice you're using version 0.9.0.11. I did not test this hack with that version so it is possible it will not work for some reason or other.

... that's the case. Although, stranger still, my Bluehost panel tells me I'm running 0.9.0.12. Of course, that could be untrue, especially since when I request an upgrade, it offers to install v. 0.9.0.12.

I suggest, even if you get the hack working, that you upgrade to version 0.9.1b.

OK, cool. Now please allow me one more probably obvious question from a newbie (and one that probably belongs in a different topic. I use Fetch to handle everything. So, once I've downloaded the 0.9.1b batch, should I just drag and drop everything from the blog folder into my public_html folder... with the exception of skins (where the files have been modified and personalized, etc.)?

I don't know what Fetch is, but pretty much "yes". Make sure you're starting in the local (PC) folder that has 'admin' and 'conf' and so forth, then just get them all into your server. I would start by deleting all the folders and files on your server (except skins) just to make sure you get the new ones. The FTP thing I use goes by date stamp, but sometimes the date of the newer file can be older than the date you unzipped the package, meaning if you don't delete your server files you'll have the older one.

Aw crap I always do this. Download your server version of conf/_config.php because it contains your database connection data. You will want to edit the new one before you upload. 4 lines for your database connection, one line for your baseurl, one line for your email addy, and one line saying "config_is_done".

Another important file to keep is conf/hacks.php IF you've written one. If you didn't actually create it then it doesn't exist, but if you have then for sure make sure you have a copy before deleting all your server side files.

I would also suggest uploading the newest version of skins/custom because IF something goes wrong you will want to ask yourself "does the official custom skin work?" before tearing your hair out. If your skin uses that name then simply rename the folder and after you're successful you will be able to select your skin by it's new name from the back office.

Once all the new stuff is on your server you need to go to "domain.tld/path_to_blog/install/ and tell it you are upgrading from a different version of b2evolution. All your posts and comments are stored in your database, so this option will tell b2evolution to NOT try to install new stuff. It'll only do the changes you need done.

After that you'll have to start over with any hacks you did that are outside skins and conf/hacks.php, meaning core file hacks. Like this one!

OK. I understand that all and am going through the process of revising each file. And I rewrote all the necessary bits in the conf/_config.php file, so that should be fine.

The only part I'm not sure I get is this:

EdB wrote:

Once all the new stuff is on your server you need to go to "domain.tld/path_to_blog/install/ and tell it you are upgrading from a different version of b2evolution. All your posts and comments are stored in your database, so this option will tell b2evolution to NOT try to install new stuff. It'll only do the changes you need done.

Is this something else I need to do using phpMyAdmin or something. I thank you in advance for your patience.

Awsome! Looks like the formatting all took! And the hack now works correctly -- well, I mean, I presume it will once I re-hack it on the various .php files. So does the YouTube one I added some time ago, which was the only other hack I've added so far. (Now this is the something I was talking about earlier with regards to "learning it the hard way.")

Thank you a g-d ton for walking me through this. If I had points, I'd send them your way.

EDIT: Damn, I spoke too soon. It's still behaving as though the correct answer (human) is incorrect. I'm stumped, but since I turned trackbacks/pingbacks off, I'm not as hellbent on installing this hack.

I'm thinking it's probably not your skin. I'm leaning towards a term I used to know I didn't understand but just got reminded I should know about: register globals. I've no idea what it means, but I'll be their OFF with your host.

I'm hoping SOMEONE explains why my hacks suck when register globals are off, and how to make this work in that case.

EdB: without register_globals (which is highly recommended), variables do not get automatically registered as globals.

This means: you have to query $_POST['param'], $_GET['param'], .. or with b2evo just use the param() function, e.g. "param( 'var1', 'string', '' )" would create a global $var1 and if there's nothing from GET, POST or COOKIE, it gets initialised to an empty string.

Waaay above my head, but since turning off trackbacks/pingbacks, I haven't gotten any spam lately.

(Of course, I as also wrong upthread about the YouTube business. My old posts are unaffected, but I found just now, while trying to post a new video, that I have to reallow the <object> and <param> tags but have since forgotten exactly how. Should be simple, right?)

(Of course, I as also wrong upthread about the YouTube business. My old posts are unaffected, but I found just now, while trying to post a new video, that I have to reallow the <object> and <param> tags but have since forgotten exactly how. Should be simple, right?)

i have just successfully installed Ed's turing test hack, on v.0.9.1. i have a couple of notes:

it is true that, if register_globals is set to OFF on your server, the hack will not work. it will fail at the point where the actual test occurs, and always return a negative response. my solution to this was to put an .htaccess file in my blog directory, with this in it:

I've got to get a handle on this! Now I know how to turn off register globals, so that'll allow me to make mine fail. Once I make mine fail I'll be able to see how to make it work again. Problem is I don't have a .9.1 or 1.6 installation to play with. I am now working on some of my older hackage for the .9.2 release, so that'll be where I go. The database is identical so hopefully the hack will carry forward, but it's got to work for ALL users else it's another lame "it works for me" hack. I try to not be lame ... publicly ;)

Finally had some time to tinker with this. Used the sample.htaccess bit to turn off $register_globals in my test installation and (of course) got the same problem as people were noticing. Installed the corrective action blueyed suggested and (of course) it works.

The first post in the thread is now the latest and greatest version. AFAIK all issues have been corrected. I also put the "edit this then that" into the order they'll show up in a directory listing just because it seems cool that way.

I RARELY get comments, but I certainly don't get automated comments. I'll be surprised if you (a) come up with a reasonable question and answer, and (b) suffer from any automated spam. I got ONE spam-like comment, but it was obvious the person really was a human out there. It tried to relate it's linkage to the post it commented on. I - of course - deleted/banned/reported the url it tried to post. It forgot to put :// in it's link. Duh... Anyway hopefully this hack serves you as well as it's served me. I've got trackbacks turned off so I get no spam from that direction. I block referer spam with a combination of .htaccess for the major keywords and (of course) the antispam central system.

I have it working in one skin - but I've applied a different skin to one of my blogs and that second skin (weddings blog - lt333gray) doesn't show the turing test field and gives a 404 when trying to leave comments. Any idea where this went astray?

l33t_gray was a funky skin. She pulled out all the stops to make it be what it is. Still you should be able to get this going, though I haven't tried it in that skin.

Did you modify skins/_feedback.php or skins/yourskin/_feedback.php for the skin it's working in? In the case of l33t_gray you will have to check out skins/l33t_gray/_feedback.php and see what the author did to make the form fields happen, then sort of tweak this hack to make it match.

I'll download the skin but no promises on getting time to work on this. Mostly my b2evolution time goes to skin-related stuff for 1.8, and the antispam stuff I do. I'm not even sure if my test installation of 0.9.2 has this hack in it or not, so that would be another roadblock to me giving you some help with this.

I had looked at skins/_feedback.php and its a standard (blank) skin file. OOPS, I wasn't careful in which file I had selected to open. The Gray skin does use a custom file. I'm going to delete it and see what happens to my CSS.

I'd rather you give me some places to look for problems than you spend time figuring out for me. I don't have a coding background, but I can usually dig up small things like this.

>>>
Works fine now, I just deleted the edited _feedback.php - sorry for not being careful the first time :oops:

my answer shows up on the "Text Box" ... it is automatically put there.

I attached my feedback file.

Also, could you post a link to the latest version of this hack. The first post on this thread has some code, then there are some comments to add/modify some lines, and lots of comments... I am not sure what the final version looks lile.

I got this working. I am still using .9.0.1 and over the past 6 weeks there has been a ton of comment spam.

This below is the code I used in the second change to _feedback.php around line 200. It is a little different to that posted at the start of this thread perhaps because my b2evolution version is even older and does not use php to produce the feedback form.

The guy that installed b2evolution for me installed it in my root directory so I am not sure which files are b2 evolution and which are not, and just the fact that I had it installed for me means that I am less inclided to upgrade. Till the comment spam started it was not necessary anyway. But now with this Turing Test I may be able to use .9 for another 10 years, assuming I am alive for that long.