Try Out the New WordPress Plugin

[jorge...@gmail.com]

Hey guys after some work I have finally finished working on the
plugin. It's not the final release, instead I would like you guys to
try it out first if you don't mind. Everything seems pretty stable and
working perfectly fine but I'm aware that many people have different
set ups. You can get the plugin at http://www.blaenkdenum.com/downloads/projects/recaptcha-2.8-RC1.zip
. I would like to know what you guys think about it as well as if you
have any problems or criticisms. You can see some of the features and
things that have been fixed in this release at the 'Change Log'
available here [ http://code.google.com/p/recaptcha/wiki/TodoWordPress
]. I recommend you first deactivate the plugin you already have (No
need to remove it since they are in different folders) then simply
upload this one and enable it.

Among the many new features are the ability to choose the language for
the reCAPTCHA interface, the theme (from a list of presets already
available from reCAPTCHA), set the tab index (This is necessary since
different installations will use different ones), the option to not
show the CAPTCHA to Admins, and the ability to show the CAPTCHA on the
registration form.

There is now also integration with MailHide. This plugin will now scan
any page that is about to be viewed for emails and hides them using
the MailHide method. Although this might seem slow it definitely isn't
(It's a WordPress filter). The plugin scans for plaintext emails and
hyperlinked emails which have the href attribute set to a plaintext
email or mailto:email. One can also bypass this behavior using special
[nohide][/nohide] tags.

The hidden emails can be styled using the emailrecaptcha class. There
is also the ability to not hide emails from admins.

MailHide is dependent on the mcrypt [ http://mcrypt.sourceforge.net/ ]
which most servers should have installed by default. However if it is
not and MailHide is enabled, it /should/ give an alert and it will not
work (Instead of simply crashing).

Here are some screenshots of the options menu:
http://i31.tinypic.com/vhuirm.jpg
http://i28.tinypic.com/21kcoox.jpg

More information available here [ http://www.blaenkdenum.com/official-recaptcha-wordpress-plugin-28-preview/
]

Please try it and let me know if you like it! If you guys have any
final suggestions, criticisms, or whatever tell me now so that I can
do the work and hopefully release the plugin soon.

[reCAPTCHA Support]

Hey!

Fantastic job. A few comments:

• From the todo list "Make XSS-proof. Apostrophes are allowed in email matching regex for MailHide?, can it be used to escape out of Javascript." Did you test XSS in the extension? I'd be most worried about somebody being able to do XSS via the comment field.
• About XHTML compliance -- the fix essentially disables the <noscript> version of reCAPTCHA. Sadly, there isn't a good way to get <noscript> working while being XHTML compliant.
• Is it possible to avoid linking to recaptcha.css on every page view? Adding another stylesheet means it takes another round trip to load the page? Only two of the styles are used on standard user pages -- maybe it makes sense to just inline them?
• Any chance of getting rid of the "save the comment in the DB if the CAPTCHA failed" stuff, which causes things that reCAPTCHA catches to show up in the moderation queue?

- Ben

--
reCAPTCHA: stop spam, read books
http://recaptcha.net

[jorge...@gmail.com]

-XSS: That's why I haven't really released it yet (Of course I was
going to get your permission if I were anyways). I'm no expert in XSS
unfortunately. I did use a vulnerability scanner from Acunetix
[ http://www.acunetix.com/ ] which said that everything was fine (Of
course I'm not trusting it 100 percent), and I'm in the process of
looking for someone who really knows these things to test it (I'll
probably ask on the WordPress forums).

-Yeah, I did remove that part as is stated in the to do list. So I'm
assuming this is fine given how there's no other way to be XHTML
compliant (Which many users want or need before they're able to use
it)?

-Well I only did it because I figured that it'd be a simpler way since
anything reCAPTCHA related would be in the stylesheet. I most likely
can inline them but I was advised against it by some XHTML standards-
knowing people, one of them said that inlining styles was on the way
out (Probably by the next XHTML Standard version). Of course I could
inline them if you like. In this case then I will have to remove the
hidden email styling and keep the notice about being able to style the
emailrecaptcha class. So if you would like me to inline them instead
let me know.

-I think it is. Note however that I already fixed the problem with
Akismet, the only other problem is that the comments are still saved
in the database just not shown (marked as spam), but there are no
longer conflicts with Akismet. I believe the line that is causing it
to go to the moderation queue or at least show up as spam is:
add_filter('pre_comment_approved', create_function('$a', 'return \'spam
\';'));
I think I'm just going to, right after this line, add a line that
deletes the comment from the database.

I'll be working on the last one for now since it's the one I know for
sure you want me to do. Let me know about the rest (Except for the XSS
one, I'm working on it).

On May 17, 12:25 pm, "reCAPTCHA Support" <supp...@recaptcha.net>
wrote:

> Hey!
>
> Fantastic job. A few comments:
>

>    - From the todo list "Make XSS-proof. Apostrophes are allowed in email
>    matching regex for
> MailHide?<http://code.google.com/p/recaptcha/w/edit/MailHide>,

>    can it be used to escape out of Javascript." Did you test XSS in the
>    extension? I'd be most worried about somebody being able to do XSS via the
>    comment field.

>    - About XHTML compliance -- the fix essentially disables the <noscript>

>    version of reCAPTCHA. Sadly, there isn't a good way to get <noscript>
>    working while being XHTML compliant.

>    - Is it possible to avoid linking to recaptcha.css on every page view?

>    Adding another stylesheet means it takes another round trip to load the
>    page? Only two of the styles are used on standard user pages -- maybe it
>    makes sense to just inline them?

>    - Any chance of getting rid of the "save the comment in the DB if the

>    CAPTCHA failed" stuff, which causes things that reCAPTCHA catches to show up
>    in the moderation queue?
>
> - Ben
>

> On Fri, May 16, 2008 at 10:22 PM, jorgepbl...@gmail.com <

> >http://www.blaenkdenum.com/official-recaptcha-wordpress-plugin-28-pre...
> > ]

[jorge...@gmail.com]

I spent a while working on the last one while having a feeling that it
was already implemented, and it is. After the page is reloaded and the
comment data retrieved this is executed:

wp_delete_comment($comment->comment_ID);

so yeah the comment is already being deleted (I was going to do the
same thing but through a database query). The only reason that there
were problems before was because Akismet got ahold of the comment
BEFORE reCAPTCHA could delete it. This priority problem has been fixed
though and I've tested it and it does indeed work.

And another thing about the stylesheet: some things could indeed be
inlined but there are new things such as a notification that the
reCAPTCHA was wrong (A simple <p>, because before the page would
simply reload with no indication as to why). This is definitely going
to have to be styled and I think the most intuitive and logical way is
to keep that stylesheet there since users will see it and style it
there. Honestly there isn't much of a performance impact especially
since the stylesheet isn't huge or anything. For this reason, my
personal preference would be to keep the stylesheet. If users complain
then I will definitely remove it. Of course I could always simply
state in the readme or installation instructions what classes can be
styled and what they correspond to but if I do this then the default
look of many things will be really ugly because I won't be able to
inline style it (Otherwise whatever styling I do that way will have
highest precedence over any other unless I think they mark every
attribute with !important). Either way I'm about to post in the
WordPress forums telling people about the plugin and asking for their
opinion on this and other things. I don't mind inlining, I just don't
think that a separate small neat stylesheet isn't much of a problem.

On May 17, 2:12 pm, "jorgepbl...@gmail.com" <jorgepbl...@gmail.com>
wrote:

[Deas]

Excellent! I have a quick request. (Well, quick to request anyway - I
don't know how time consuming implementation might be.)

Is it possible to make an option to remove the reCAPTCHA from the
comment forms on every post? (I'd love to use it for the registration
only, since I'm a small blog that mostly has issues with registration
spam...) Or perhaps an option so that it excludes registered users
from having to fill out a reCAPTCHA? Thanks.

Awesome work!

[Deas]

Also - it appears that the theme chosen from the dropdown menu only
skins the comment form reCAPTCHA. The registration page remains the
default red.

[Jorge Peña]

As for the first request, that's already in the to do list and I do have intentions on implementing it; shouldn't be too hard.

For the second: Yes I know that, I specifically made it that way because the other themes don't look good. Already I have to change the width of the registration page to accommodate the reCAPTCHA form. If you REALLY want to change the theme let me know and to what theme you'd like to change it to.

I'll let you know once I'm done with your first request.

[reCAPTCHA Support]

Hey,

On Sat, May 17, 2008 at 2:12 PM, jorge...@gmail.com <jorge...@gmail.com> wrote:

 
-Yeah, I did remove that part as is stated in the to do list. So I'm
assuming this is fine given how there's no other way to be XHTML
compliant (Which many users want or need before they're able to use
it)?

This is a decision that's up to you. However, keep in mind that often the minority group is the loudest. I personally think that most bloggers would prefer to support non JS users rather than to support the w3c validator. People who believe that standards are more important than users can always comment out the relevant lines of code.

Anyways, if the new version doesn't support non-js users, there should at least be instructions stating that in a <noscript> tag. 

 

-Well I only did it because I figured that it'd be a simpler way since
anything reCAPTCHA related would be in the stylesheet. I most likely
can inline them but I was advised against it by some XHTML standards-
knowing people, one of them said that inlining styles was on the way
out (Probably by the next XHTML Standard version). Of course I could
inline them if you like. In this case then I will have to remove the
hidden email styling and keep the notice about being able to style the
emailrecaptcha class. So if you would like me to inline them instead 

let me know.

Yeah, I have no idea what the "standard" is for wordpress here. Maybe a wp hacker can tell if there's a better way. 

 

-I think it is. Note however that I already fixed the problem with
Akismet, the only other problem is that the comments are still saved
in the database just not shown (marked as spam), but there are no
longer conflicts with Akismet. I believe the line that is causing it
to go to the moderation queue or at least show up as spam is:
add_filter('pre_comment_approved', create_function('$a', 'return \'spam
\';'));

I think it's the fact that the comments are in the database that causes people to think there is a problem.
 

 

I think I'm just going to, right after this line, add a line that
deletes the comment from the database.

So the issue is that I used the database as a temporary place to save the comment (so that we could present it if you got the captcha incorrect). I think the solution might be to use a different table for this sort of thing, or maybe to store it in the session.
 

[Jorge Peña]

About the XHTML standard, I could add an option stating the consequences of being XHTML strict compliant, and if checked those offending lines are omitted from the output.

The WordPress 'standard' or tradition is to include a separate stylesheet. Like I said, the overhead is negligible, but if there are complaints (Which I doubt) then I will gladly remove it.

Also I have already fixed the Akismet spam illusion problem (Where people think that there is still spam), like I said, it was a hook priority problem, so all is well now. The only other Akismet related task I have is to integrate it into Akismet so that reCAPTCHA only shows when Akismet think the comment is spam (To double check). I was trying to implement this on my own but it proved more complicated than I thought so I am going to leave it for the next version, though I do have a feeling that it is possible.

[reCAPTCHA Support]

Hey,

On Sun, May 18, 2008 at 12:29 PM, Jorge Peña <jorge...@gmail.com> wrote:

About the XHTML standard, I could add an option stating the consequences of being XHTML strict compliant, and if checked those offending lines are omitted from the output.

I guess. It's sort of problematic how to phrase it. If the option says "Be XHTML Compliant", people would just randomly check it. If you say "Be XHTML compliant at the expense of breaking things for non-javascript users" it just looks silly.

Also I have already fixed the Akismet spam illusion problem (Where people think that there is still spam), like I said, it was a hook priority problem, so all is well now. The only other Akismet related task I have is to integrate it into Akismet so that reCAPTCHA only shows when Akismet think the comment is spam (To double check). I was trying to implement this on my own but it proved more complicated than I thought so I am going to leave it for the next version, though I do have a feeling that it is possible.

I think that the comments that reCAPTCHA catches will still go into the moderation queue in the new version. People seem to get confused because they get moderation emails when reCAPTCHA marks something as spam.

Keep in mind that there's a bit of a hack that removes the comment from the database if you're using a normal browser. You may want to remove this line:

wp_delete_comment($comment->comment_ID);

as it will simulate the behavior of a spam bot.

- b

[Jorge Peña]

About the XHTML compliance option, I phrased it "Be XHTML 1.0 Strict compliant. Note: Bad for users who don't have Javascript enabled in their browser (Majority do)." We can only be so user friendly.

It only removes the content from the database if you're using a normal browser? The definition of wp_delete_comment ( http://xref.redalt.com/wptrunk/wp-includes/comment.php.source.htm#l275 ) seems pretty much like it is doing what it should be doing to me. I was going to do what the function is already doing until I noticed that you were already calling it. Isn't that what we want it to do? To delete the comment from the database? How does that simulate the behavior of a spam bot? Just wondering, pretty confused.

As for the emails for the moderation queue, like I said I've already tried it with email notifications option set on and I haven't gotten any emails about this so I really do think the problem has been fixed. However, if anyone tells me that it still occurs though I highly doubt it then I will definitely look into it. But from what I can tell, the code is doing exactly what it should be doing so that it doesn't happen.

[Jorge Peña]

I'ved updated the plugin and fixed the bugs and implemented the features that you guys were talking about (As well as a guy from WordPress was talking about). Check it out and let me know what you think! http://www.blaenkdenum.com/recaptcha-wordpress-plugin-28-release-candidate-2/ I hope it's a bit better.

[reCAPTCHA Support]

Hey,

On Sun, May 18, 2008 at 1:27 PM, Jorge Peña <jorge...@gmail.com> wrote:

About the XHTML compliance option, I phrased it "Be XHTML 1.0 Strict compliant. Note: Bad for users who don't have Javascript enabled in their browser (Majority do)." We can only be so user friendly.

I think the options page should be as minimal as possible. If you have to put a "note" there (eg, don't touch if confused or this might break things for users without javascript), it really shouldn't be an option :-).

Here are some potential changes for the options page:

• Language -- does wordpress provide an API to get the language the blog is displayed in? If so, no need for an option.
• SSL -- can you describe the problem the user was having? The plugin should detect if ssl is necessary, and if so, just use it.
• XHTML -- IMHO, should be done by changing the code.
  

It only removes the content from the database if you're using a normal browser? The definition of wp_delete_comment ( http://xref.redalt.com/wptrunk/wp-includes/comment.php.source.htm#l275 ) seems pretty much like it is doing what it should be doing to me. I was going to do what the function is already doing until I noticed that you were already calling it. Isn't that what we want it to do? To delete the comment from the database? How does that simulate the behavior of a spam bot? Just wondering, pretty confused.

Because the deletion happens on a different page request (a redirect). Spam bots usually don't follow the redirect (as such, the marked as spam version stays in the DB). We need a way to keep the comment data around on the redirect without having to put the comment in the comments table

[Deas]

Well, I just want to compliment you on the speed of your responses. I
am bowled over at how fast suggestions and bugs are being tackled.
(And no - I'm not particularly hung up on the registration page theme
- I agree with you that the red looks the best on that page.)

The comments though...I'm looking forward to that update! Maybe for
the next version of the plugin? That way you can go ahead and
officially release this iteration. Thanks again.

[Jorge Peña]

Deas: What update? The comments? Yeah I've included that feature already, it's the 'Use recaptcha for comment spam protection' option in the options page. You don't see it? After you change it you might have to flush/clear your cache plugin (wp-cache, wp-super cache, etc.) if you're using one and your browser cache. Thanks for the kind words!

Ben: I'll work on that tomorrow maybe, I just want to take a little break heh, but all you said is definitely possible. Except for the langauge detection, I'm not too sure about that one. And by the way I understand your desire to keep things simple, I like that too, but trust me for a wordpress plugin this is a pretty simple settings page, and straightforward too. So don't worry too much about that.

I am not sure I can detect the language of the WordPress installation through an API call, nevertheless that option is really straightforward.

As for the SSL option, maybe there's a way to detect SSL through PHP? If so then I can do it, I'll look into it later. EDIT: I think I can use $_SERVER['HTTPS'], but then shouldn't this feature be directly implemented into the recaptcha PHP library instead then, since it's going to be automatic?

About the XHTML, I honestly think it'd be best to keep the option. Many people have complained about wanting it and if they could edit the code themselves then they would've done it already. Maybe I could add some type of global variable(s) which users can configure but that would defeat the purpose of even having an options page (Then again, it could work, what do you think).

I see what you mean now about the comments. What we can do is create a new database table called something like wp_recaptcha where the comments will temporarily be stored, and if they are legit then they can be sent to the comments database and removed from the temporary location. However, the ONLY problem is that the hooks are just that as far as I know, hooks, so since we're hooking to the preprocess_comment hook, it means that our function will do whatever we want it to do when the preprocess_comment event comes up but after our function is finished, wordpress is going to go ahead and do what it would've done anyways. It seems like that's what it would do at least but of course I'll give it a try.

[reCAPTCHA Support]

Hey,

On Sun, May 18, 2008 at 11:09 PM, Jorge Peña <jorge...@gmail.com> wrote:

Ben: I'll work on that tomorrow maybe, I just want to take a little break heh, but all you said is definitely possible. Except for the langauge detection, I'm not too sure about that one. And by the way I understand your desire to keep things simple, I like that too, but trust me for a wordpress plugin this is a pretty simple settings page, and straightforward too. So don't worry too much about that.

No problem, you've done a lot of great work!
 

I am not sure I can detect the language of the WordPress installation through an API call, nevertheless that option is really straightforward.

Agreed, but if it's possible not to have an option, it's for the best.
 

As for the SSL option, maybe there's a way to detect SSL through PHP? If so then I can do it, I'll look into it later. EDIT: I think I can use $_SERVER['HTTPS'], but then shouldn't this feature be directly implemented into the recaptcha PHP library instead then, since it's going to be automatic?

I wanted the php library not to access any of the super globals like $_GET or $_POST.  

 

About the XHTML, I honestly think it'd be best to keep the option. Many people have complained about wanting it and if they could edit the code themselves then they would've done it already. Maybe I could add some type of global variable(s) which users can configure but that would defeat the purpose of even having an options page (Then again, it could work, what do you think).

As a maintainer you get to make the tough decisions :-).

[jeremyclarke]

As a serious WP admin I'd like to note that ALL options should be
changeable through the admin interface and should never require
editing the code itself. WP has finally got a system going that lets
you update plugins automatically, and the value of just updating
(versus re-applying patches) is very very important. Any customization
you make to the plugin makes you less likely to update.

The best solution would be to have two sets of options on the page
"CONFIGURATION" and "ADVANCED SETTINGS", and put any questionable or
unpopular settings in the advanced section.

One thing to note about the values involved in the language issue is
that there is only one place wp users can set their language and it
applies to the whole blog, so sites that want an english backend (more
stable, more supported plugins) and code their template to be
localized might want a localized recaptcha even though their site is
officially 'en'. I run several sites like that and we end up having to
avoid all plugins where the language is hardcoded (though we're a
special case, and almost no plugins are translated into all the right
langauges for us).

Thanks for the insanely useful plugin!

Jeremy Clarke
Code and Design | http://globalvoicesonline.org

[Jorge Peña]

@jeremyclarke: So I take it you're okay with my approach then? To have a language drop down list?

Also, do you guys think that SSL should be automatically detected and set within the plugin or have it manually modified as an option in the settings?

[jeremyclarke]

I think the best way would be to look for a global language variable
(as set in wp-config.php by define ('WPLANG', ''); ) if it's there, it
should probably be the default setting, but for people with no value
there I like the idea of a dropdown menu with the other available
translations. It's not very common to do it that way but IMHO it
should be, and having recaptcha be as available as possible is really
important (it's the only captcha I've seen for wordpress that has good
accessibility etc.).

If there's a way to do automatic SSL detection then that definitely
sounds better than changing a setting, but I'm no expert on SSL so I
don't know the ins and outs (i.e. I don't know if some people might
want it off even though the autodetect would say that SSL is on).

[Jorge Peña]

I've released RC3, it fixes some CSS bugs and includes auto detection of SSL. Today I will implement the language feature you said. The default value will be autodetected if one is set in wp-config and if not then it'll be default to English, but it'll still be changeable through the drop down list. Any other requests or suggestions?

RC3: http://www.blaenkdenum.com/downloads/projects/recaptcha-2.8-RC3.zip

[Jorge Peña]

Here is release candidate 4: http://www.blaenkdenum.com/downloads/projects/recaptcha-2.8-RC4.zip
It fixes some styling issues as well as, hopefully, some registration issues. One person claims that when they have recaptcha on the registration page, users don't even have to fill in the CAPTCHA and they can register. Doesn't happen with me and no one else has mentioned it so I think it might be an isolated case. If anyone encounters any bugs/problems please let me know.

Automatic language detection proved too difficult and not at all reliable (The only way seemed WPLANG, which isn't always defined. In fact, it rarely is. And the language codes differ). Since this would only be for the default value, I decided to just forget about that 'feature' as a whole. After all, it will be set to English by default and if anyone wants it to something else they can easily change it.

[Deas]

I've got another feature request - but it's not really a priority. If
you've ever used SABRE (Simple Anti Bot Registration Engine) by Didier
Lorphelin (http://didier.lorphelin.free.fr/blog/index.php/wordpress/
sabre/), you know that there is a log for rejected registration
attempts which you can choose to put on your Wordpress Dashboard. Is
it possible to implement something like that for the reCAPTCHA plugin?

[Jorge Peña]

Definitely, I can simply make a counter which counts the failed CAPTCHA attempts, only for registrations though? It would definitely add unnecessary overhead although it shouldn't be too significant. I will have to investigate on how to show it on the dashboard and possibly even make a widget, but I think I will do that for the next version instead as, like you said, it's not very important.

[Jorge Peña]

You mean something like the Akismet plugin right that says 'akismet has block x spam'.

[Deas]

Here are 2 examples of the kind of counter I'm referring to. (Both
from SABRE.)
http://www.deasrichardson.com/counter1.png
http://www.deasrichardson.com/counter2.png
- Deas

[Jorge Peña]

I can probably get you a counter for the stopped registrations and maybe one for the successful ones (Though I think that's redundant or unnecessary), the whole list though of the IP Address and what not seems like overkill for now. I guess you can use that information to somehow add it to a block list later or something. I would have to create a new table to store the information of those people that failed. Honestly it seems unnecessary and overkill. The counter though I could probably get you, if you want it for cosmetic purposes like the Akismet widget that says 'Akismet has blocked blah spam'.

[Deas]

Yeah, I guess that makes sense. I like the "registrations stopped" and
"registrations accepted" fields, though. Those are really what I'm
after. It's nice to know it's working.

[Jorge Peña]

By the way guys, the new plugin available here: http://wordpress.org/extend/plugins/wp-recaptcha/

It says 2.8 but it has a few changes that you guys don't have in your versions. I suggest you download and install it (It uses the wp-recaptcha folder now not the recaptcha folder, so disable + delete the old one. If you already had a revision that used the wp-recaptcha folder then simply upload and overwrite) so that you can do automatic updates.