I wrote a couple of special contact forms. To integrate the gotcha module I need to:
1. keep up to date with your code-changes
2. copy a lot of code.

Is it possible to make a function I can call from my special forms and in which all gotcha-handling will be done? If so, please craft it so that, if this module needs more parameters, these are added at the end with suitable defaults?
For example: in your version 1.9 2007/10/22 you added a new case: contact_mail_user. You had to split up the code into the cases each with special parameters.
Is it possible to put the code-part after the cases into a new function, so everybody can call this function with their own parameters?

May be also a function can be written to add all special form-fields to my own form.

Thanks,

PROMES

CommentFileSizeAuthor
#13 gotcha.module.txt21.7 KBPROMES
#13 gotcha_api.txt1.73 KBPROMES
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

NancyDru’s picture

Status: Active » Postponed (maintainer needs more info)

Gee, this module started with such a simple idea and is evolving into something big!

I think I sort of understand what you're wanting, but it would help me get my head around this if you could give more exact details about what you want. The switch/case code is just because there are slight differences between the site form and the user form; the rest is pretty much taken from the contact module.

keep up to date with your code-changes - Lots of luck! I keep tweaking it to make it work on my live sites, which seem to experience things a bit different from my test sites. I guess it could be that I am just not a real spammer and have trouble thinking like one.

PROMES’s picture

I created a form for a translation shop where a potential customer can ask for a quote about a translation of a book or documentation. It is like a normal contact form but the form contains also several special fields about: the size (in pages) of the original, what type of file it will be in (Word, Excel, PDF, paper, ...), from and into what language it should be translated and so on.
This requires pieces of your module in two functions:
a. creation of the form
b. validation of the form
I want to keep the submit function in my hands to process all special fields into the e-mail.

It would be very easy if:
a. the form creation can call a function that will add the Gotcha fields, like it does for the contact forms, but without jumping to your validation/submit function
b. at validation stage: call your function to validate the Gotcha-part and return with a yes/no or quantity field, indicating succes/fail in sending the mail. I can add my own validation afterwards if the mail can be send.

I can send you an example from if you send me a message through my drupal contact form.

PROMES’s picture

An exellent example is the form at http://drupal.org/node/68265. I did use this one as base for several special contact-forms.
I had been looking for this page but couldn't find it. I see you have been involved.

NancyDru’s picture

Status: Postponed (maintainer needs more info) » Active

I have contacted the owner of the Contact Forms module about how the two might play better together.

I'm guessing, from the way you worded this, that you use both this custom form and the standard form?

PROMES’s picture

Helas, not quite. I also use very customized forms.

NancyDru’s picture

You don't want to make this easy, do you?

PROMES’s picture

I don't understand what you mean now.
But I'll wait till you finished with the owner of the Contact Forms module and see whether this is what I need.
Still thanks for your quick replies and understanding. And I like the module very much. It kept away a lot of spam in the couple of days I installed the software on 2 sites. It's a pity I have to convert my old Drupal 4 sites first to use the module on these sites as well. But that's upcoming.

NancyDru’s picture

I'm still trying to get my head around this request. Looking back at #2, Gotcha does not create or validate the form; it only intercepts the submit function.

Here's what I think you want:

1. A pre-processing call that allows you to specify additional fields to be passed through the spam filters.

2. Collection of the contents of those fields to pass through the spam filters.

3. Some notification back to your form processing to indicate whether or not it was flagged as spam.

4. Logging of all your data - and the ability to return that to you for formatting on "view" or "resend."

#1 should be possible. I would see it as making the field collection a bit more flexible (e.g. even the standard fields would be handled this way).

#2 is a bit more daunting as the spam filter is set up basically for nodes - it looks at a header (title, subject) and a body. This would require someway of specifying which of your fields should be handled as which type and then sticking those fields together somehow that doesn't, in itself, raise any additional concerns to the filters.

#3 can probably be handled by just adding another $form-values field with the probability and/or spam indicator.

#4 requires at least a small change to the log to add a "custom" type (or do we need to be even more granular?). But then the problem is how to I keep all of your fields? One thing that comes to mind is to know that a "custom" entry means that the body field is actually a serialized array of all the data collected.

Does it sound like I'm beginning to understand the request?

PROMES’s picture

I think you are looking another way I do.
In pseudo code I wanted to do something like:

a. in my form building function:
Create all form fields the usual way. Then add the special gotcha fields in front:
$form = gotcha_start_formfields() + $form
I keep my own submit field !

where gotcha_start_formfields() =
function gotcha_start_formfields() {
// We'll call our hidden field "Subject" so it sounds enticing.
// We provide a message for browsers that don't hide the field.
$form['Private_Message'] = array(
'#type' => 'textfield',
'#title' => t('Subject'),
/* '#weight' => -5, Place it high on the form. */ <<<-- not needed anymore or make it an implementation comment
'#prefix' => '

',
'#suffix' => '

',
'#description' => t('This field is for computer-generated email only and should not be visible. If you can see it, please ignore it.'),
);
return $form;
}

So if more form-fields are needed in the future, they can included in above function.

b. in my validation- or submit function: check for spam with gotcha. If none, continue with my own affairs:
gotcha_check_for_spam(list of needed fields);
do my own validation and send the mail

where gotcha_check_for_spam() =
your submit function split up into 2 separate functions:
1. gathering the data needed for the validation + call to validation (see #2) + send the mail
2. your anti-spam validation including: if spam: goto the gotcha_goaway_page otherwise return to the calling module.

I only will use the #2 validation.

I will try to "rewrite" your module with my idea coming week and if you agree, upload it here.

NancyDru’s picture

Okay, I think *all* we really need is just a hook similar to what you call the "start" routine.

Hook_gotcha

Provides the form name and a field list for the form intercept routines.

Key Value
Form The name of the form(s) to intercept.
Fields An array listing all the field names that need to be examined for spam.


'field_name' => array('log' => TRUE/FALSE, 'scan' => TRUE/FALSE, 'scan_as' => 'header'/'body')

I think this would necessitate a complete rewrite of the logging function.

On the form intercept, I would gather all the scan-able fields and run them through the spam filter. When done, I would add another field to $form_values called "is_spam," which would be a TRUE/FALSE indicator.

I think the standard forms would then look something like this:

/*
 * Implementation of hook_gotcha.
 */
function gotcha_gotcha () {
  $process = array(
    'contact_mail_page' => array(
      'type' => 'site',    /* This is a special indicator for logging. */
      'cid' => array(
        'log' => TRUE,
        'scan' => FALSE,
        'scan_as' => NULL,
        ),
      'name' => array(
        'log' => TRUE,
        'scan' => FALSE,
        'scan_as' => NULL,
        ),
      'mail' => array(
        'log' => TRUE,
        'scan' => FALSE,
        'scan_as' => 'body',
        ),
      'message' => array(
        'log' => TRUE,
        'scan' => TRUE,
        'scan_as' => 'body',
        ),
      'subject' => array(
        'log' => TRUE,
        'scan' => TRUE,
        'scan_as' => 'header',
        ),
      ),
      
    'contact_mail_user'   => array(
      'type' => 'user',    /* This is a special indicator for logging. */
      'cid' => array(
        'log' => TRUE,
        'scan' => FALSE,
        'scan_as' => NULL,
        ),
      'name' => array(
        'log' => TRUE,
        'scan' => FALSE,
        'scan_as' => NULL,
        ),
      'mail' => array(
        'log' => TRUE,
        'scan' => FALSE,
        'scan_as' => 'body',
        ),
      'message' => array(
        'log' => TRUE,
        'scan' => TRUE,
        'scan_as' => 'body',
        ),
      'subject' => array(
        'log' => TRUE,
        'scan' => TRUE,
        'scan_as' => 'header',
        ),
      ),
}

Now, how to do the little extra processing? And how to save your submit routine name...

PROMES’s picture

I have been thinking about the strategy to go.

I interpret your point of view:
for each form, wanting to be checked on spam, this module has to know everything about the form to do the checking for spam for every possible form someone can imagine. And then this module also has to know how to format and send out the e-mail, even if there are, depending on the input, more or less fields to send by mail. In my opinion this would make it a very heavy module.

My point of view is:
this module is excellent as is: use it for default Drupal forms, and maybe, some other general, simple forms. But also it should provide some basic tools for other modules: these modules should call some (previously described) gotcha-functions to know the result: yes/no spamming.
I think then the gotcha module will stay easy to maintain. It doesn't have to know anything about other modules implementation and can be used by a lot of other modules, like mailattach and forward. And the code-base will only increase a bit.

This can be reached by 2 methods:
1. one module having both the implementation and the tools
2. split the gotcha module into 2 modules:
a. a tools function module to be used only by other modules
b. an implementation module for the Drupal forms, using the tools function module.

If you go for my direction for the future of the module, I will spend some time this week for an implementation. I wait for your reply.

NancyDru’s picture

Title: Special functions » Support for Custom contact forms
PROMES’s picture

FileSize
1.73 KB
21.7 KB

Attached you will find my version. Please comment on it. I created some documentation in gotcha_api.txt.
Since I don't have experiance with hooks, maybe my calls can be implemented in hooks or other better programming ways. As far as I could see this version gives the same results as your version.

Hope to hear from you.

NancyDru’s picture

Okay, I'll take a look

NancyDru’s picture

Assigned: Unassigned » NancyDru
Status: Active » Postponed

http://drupal.org/node/171780

Since Jeremy is actively developing V3 of the Spam module and adding more form filtering, I am postponing this issue. V3 may even so grossly change things that Gotcha might become unnecessary.

PROMES’s picture

I'll wait for Spam V3.
Thanks.

NancyDru’s picture

Yeah. me too.