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).
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.
- 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 <
> 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).
> 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.
-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:
> - 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 <
> > 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).
> > 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.
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:
> -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 <
> > > 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).
> > > 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.
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.
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.
On Sun, May 18, 2008 at 6:27 AM, Deas <deas.richard...@gmail.com> wrote:
> Also - it appears that the theme chosen from the dropdown menu only > skins the comment form reCAPTCHA. The registration page remains the > default red.
> -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.
> 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 <
> > > 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).
> > > 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.
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.
On Sun, May 18, 2008 at 11:55 AM, reCAPTCHA Support <supp...@recaptcha.net> wrote:
> On Sat, May 17, 2008 at 2:12 PM, jorgepbl...@gmail.com < > jorgepbl...@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.
>> 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 <
>> > > 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).
>> > > 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.
On Sun, May 18, 2008 at 12:29 PM, Jorge Peña <jorgepbl...@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:
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.
On Sun, May 18, 2008 at 1:08 PM, reCAPTCHA Support <supp...@recaptcha.net> wrote:
> On Sun, May 18, 2008 at 12:29 PM, Jorge Peña <jorgepbl...@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:
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-cand... hope it's a bit better.
On Sun, May 18, 2008 at 1:27 PM, Jorge Peña <jorgepbl...@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.
> 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.
> On Sun, May 18, 2008 at 1:08 PM, reCAPTCHA Support <supp...@recaptcha.net> > wrote:
>> Hey,
>> On Sun, May 18, 2008 at 12:29 PM, Jorge Peña <jorgepbl...@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.
On Sun, May 18, 2008 at 1:27 PM, Jorge Peña <jorgepbl...@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
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.
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.
On Sun, May 18, 2008 at 7:13 PM, Deas <deas.richard...@gmail.com> wrote:
> 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.
On Sun, May 18, 2008 at 11:09 PM, Jorge Peña <jorgepbl...@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 :-).
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).
> 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).
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).
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?
> 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).
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.
On Tue, May 20, 2008 at 7:24 AM, Jorge Peña <jorgepbl...@gmail.com> wrote: > 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?
> On Tue, May 20, 2008 at 5:43 AM, jeremyclarke <j...@simianuprising.com> > wrote:
>> 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).
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?
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.
On Thu, May 22, 2008 at 5:16 AM, Deas <deas.richard...@gmail.com> wrote:
> 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/ <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?
On Thu, May 22, 2008 at 7:29 AM, Jorge Peña <jorgepbl...@gmail.com> wrote: > 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.
> On Thu, May 22, 2008 at 5:16 AM, Deas <deas.richard...@gmail.com> wrote:
>> 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/ <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?
|
