this one is a bit tricky. here's how i've decided to handle it:
- broke out the anon mail validation code into signup_validate_anon_email -- this is a function that an external module can call in it's validation process to properly validate the anon email for signup's purposes.
- added a check to automatically set uid = 0 in the signup api function if an anon email is passed in. this ensures that the proper uid is always supplied to an anon signup in the event of an external call.
- added some doxygen comments to the signup api function to properly describe how an external module can execute an anon signup.
i considered trying to make the validation for external calls happen automatically inside the signup api itself, but i think given the fapi workflow, it's better to let the calling module perform validation in it's validation cycle--this will allow for the proper setting of form errors, etc.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | anon_signup_validate_0.patch | 4.05 KB | hunmonk |
| anon_signup_validate.patch | 3.85 KB | hunmonk |
Comments
Comment #1
hunmonk commentedhm. posted patch doesn't allow for the case where an external signup doesn't use a form to collect the email. i'll post a fix for that in a bit...
Comment #2
hunmonk commentedok, attached patch is much better. code is cleaner, and it accounts for an external module passing in an anon email that was not gotten from a form.
Comment #3
dwwapplied and (lightly) tested. validation still seems to work for anon signups.
from looking at the code, there *might* be trouble in php with constructs like this:
since i've heard (i think) that if
$form_values['signup_anon_mail']is undefined, the above throws a warning, instead of just treating undefined as FALSE.if someone with php5 confirms this is a problem, we can fix it later. ;)
thanks,
-derek
Comment #4
hunmonk commentedapplied ot 4.7 and HEAD.
Comment #5
(not verified) commented