Posted by robloach on June 26, 2007 at 10:14pm
The Future Direction of Captcha is a great discussion on where the captcha modules should go and how all the different capthca solutions should come into one.
Future of Captcha
The Future Direction of Captcha is a great discussion on where the captcha modules should go and how all the different capthca solutions should come into one.
Comments
dependencies
What about dependencies?
Will/should the basic captcha module (aka captcha API or captcha_light) depend on a standalone form_id collecter module (e.g. form_store+form_collect like now)?
Personally I'm not in favour of this because it is not very user friendly/obvious how to add form_ids and it adds a lot of administrative overhead. Moreover having dependencies adds more complexity to the development (e.g. compatibility issues).
In my rewrite (last version at http://drupal.org/node/153395#comment-264105) I dropped this dependency and added an option to add more user friendly captcha administration links to all forms. The additional code for this is reasonable (about 70 lines on a total of around 432).
On the other hand I understand that there are 'architectural' reasons to put form_id collecting in a separate module. But I think it's not worth the hassle (both for users/administrators and developers).
captcha settings page
Another thing I was thinking about:
Shouldn't we move the captcha settings page(s) from the general settings (now:
?q=admin/settings/captcha) to the user management (like?q=admin/user/captcha)?Captcha is closely related to access control and user settings (
?q=admin/user), so I think it makes sense to move it from the general-everything-but-the-kitchen-sink settings category ("site configuration") to a more sensible one ("user management").Very Interesting
Hmmm, good point. I made a poll about it. Cast the vote!
comment on http://drupal.org/node/154783#comment-266259
This is a comment on http://drupal.org/node/154783#comment-266259 :
hello Rob
Well, captcha mangement is for site adminstrators only, and I think these people can live with "an option too much". It's an option after all, not something required. From a usability point of view I think you should offer a default/fallback.
These things can be easily solved by good documentation. E.g. in the source code: "
look for function captcha_capthca() for an example implementation of hook_captcha()" or a decent documentation/handbook about the captcha API. It seems overkill to me to create a separate module and directory structure for just one function of barely 20 lines.Well, CCK and Views (I'm not familiar with E-commerce) are very complex modules with very complex UI's where it is not easy to determine a sensible default. Moreover every extra option adds more complexity/bloat to the UI. Captcha, on the other hand, is a very 'simple' module with a small UI. So I, think it's the other way around: putting captha/math in a separate module would result in more administrative overhead (managing an extra module) than just offering it as a default.
new version of my rewrite (revision 52)
Hello,
I just wanted to mention that I released another version (revision 52) of my rewrite:
http://drupal.org/node/153395#comment-270126
The most important thing is that I ported the image captcha functionality from MyCaptcha to my rewrite as a submodule "image_captcha".