One last thing I'd like to iron out before going to release candidates for 6.x-2.0 is dropping the preprocess part of hook_captcha.
I think this preprocess part is a bit reinventing stuff that is already in Drupal's Form API and this reinventing makes things a bit complicated and messy (e.g. it raises some problems with the random CAPTCHA from the CAPTCHA pack module). The better way to do it is defining a form element with hook_element and doing the stuff that was previously in preprocess in a process callback. See for example captcha_elements() and captcha_process().
The preprocess part is used mostly (as far as I know) to offer case insensitive validation. I think it would make sense to make case insensitive validation a global option instead of a per CAPTCHA type option.
The only other use of the preprocess part I know of is in the reCAPTCHA module. I have to look into this how this preprocess part can be replaced with something better.
In conclusion:
Dropping the preprocess part should make the CAPTCHA API cleaner/smaller, make the CAPTCHA module code cleaner/smaller
Making case insensitive validation global should make the different CAPTCHA type modules cleaner/smaller and is simpler to do in one place (CAPTCHA core) instead of in all the different CAPTCHA type modules.
Comment | File | Size | Author |
---|---|---|---|
#12 | 463002_drop_preprocess_2.patch | 4 KB | soxofaan |
#7 | 463002_drop_preprocess_1.patch | 4.52 KB | soxofaan |
#6 | 463002_drop_preprocess_example.patch | 703 bytes | soxofaan |
Comments
Comment #1
soxofaan CreditAttribution: soxofaan commentedsolving this will also make #463008: case insensitive Image CAPTCHA only shows lower case characters go away
Comment #2
soxofaan CreditAttribution: soxofaan commentedCommitted first part of this issue: making a global option for case insensitive validation:
http://drupal.org/cvs?commit=211820
Comment #3
soxofaan CreditAttribution: soxofaan commentedCase sensitive/insensitive validation is now in
last question: can preprocess be dropped for something better?
Comment #4
wundo CreditAttribution: wundo commentedHi Stefaan,
It has been a while ;)
I'm not so sure about droping preprocess op, could we talk on IRC about it a bit?
cheers,
fabiano
Comment #5
soxofaan CreditAttribution: soxofaan commentedHi Fabiano, It's been a while indeed ;)
Don't worry, I won't drop preprocess op before I am sure of something better.
The problem is that the preprocess op is rather limited in functionality, and working with it feels like overcomplicating things/reinventing the wheel.
Take this use case for example: http://drupal.org/node/440490#comment-1601638
In this case, it would be easier if the validation itself could be done by that module, instead of only letting it preprocess the response before validation, without even knowing the original question or correct solution.
I'll try to come up with an example module that illustrates how this could be done more cleanly. I even think it's possible to do it in a way that is backwards compatible with the CAPTCHA API of 5.x-3.x and 6.x-1.x.
So nobody will be hurt :)
edit: small typo
Comment #6
soxofaan CreditAttribution: soxofaan commentedA small example to illustrate how the preprocess functionality can be achieved with standard Drupal's form API stuff. Hence my "reinventing the wheel" remark.
You can add additional process callbacks with the '#process' property. In the following example I added such a '#process' property to the default Math CAPTCHA from the CAPTCHA module. This callback preprocesses the response by adding one to it, so to get past the CAPTCHA, you have to enter one less than the real solution.
in attachment a patch to try it out with the version from HEAD (6.x-2.x-dev).
I think we should drop the preprocess op because it is much cleaner to do the same (and maybe more) with the standard Drupal Form API. It will make the CAPTCHA API smaller, cleaner and simpler, and it promotes the usage of standard Drupal techniques.
Also note that this is backwards compatible with the CAPTCHA API of 5.x-3.x and 6.x-1.x. So CAPTCHA modules that work with this "preprocessless" CAPTCHA 6.x-2.x API will also work with the old 6.x-1.x API.
Comment #7
soxofaan CreditAttribution: soxofaan commentedHere is a first patch to remove the preprocess op from hook_captcha
Comment #8
soxofaan CreditAttribution: soxofaan commentedI just updated the challenges of CAPTCHA Pack to be compatible with a preprocessless CAPTCHA API. No more need for preprocess in CAPTCHA pack ! ;)
The code of those challenges looks now much cleaner and I could remove an ugly hack from the random CAPTCHA type challenge.
Comment #9
soxofaan CreditAttribution: soxofaan commentedI also made a patch for reCAPTCHA to make that module compatible with dropping preprocess: #469594: use #process instead of preprocess (CAPTCHA 6.x-2.x API update)
Comment #10
soxofaan CreditAttribution: soxofaan commentedYay, Rob committed the patch from #469594: use #process instead of preprocess (CAPTCHA 6.x-2.x API update), so reCAPTCHA module is now also compatible with a preprocessless CAPTCHA API,
Wundo, are you still in doubt about dropping preprocess, and if so, why?
I'd like to push this ASAP, so CAPTCHA for Drupal 6 can finally get past beta.
Comment #11
soxofaan CreditAttribution: soxofaan commentedrelated issue
#473002: Provide a way to define custom CAPTCHA validation
Comment #12
soxofaan CreditAttribution: soxofaan commented(reroll)
wundo, are you there?
Comment #13
soxofaan CreditAttribution: soxofaan commentedI can't reach wundo (I also tried IRC and email), but this issue is blocking any further work on the 6.x-2.x branch,
so I decided to commit this:
http://drupal.org/cvs?commit=225020
there is always the 6.x-1.x branch if one needs the preprocess op