How and where to write Webform submit hook?

Question

I am new to Drupal(7) and hence need some help for following situations.

I have created one Webform(I have other webform too) and now instead of inserting in default webform_submitted_data table, I want for this webfrom to insert into myTable. From what I found, I need to write a hook for this. Actually I am getting confused for way to write this hook. I have below questions.

1. Where to write this hook (in which file).
2. How to write this hook only for one webform.

Please help and let me know if you need any more information for this.

Answer 1

First, be very sure before you start twisting Drupal's arm into making things work differently then they are supposed to. Rerouting the data for a Webform could potentially provide hiccups in how Webform works and this could bite you later. It may still expect the data to be saved in its own bookkeeping tables, but fail to find it there later if you overwrite its behavior.

That being said, if you wish to alter the behavior of other modules, such as Webform, you will have to write your own, tiny module. Some of these hooks can also be influenced via the templating layer (using your templates template.php file), but this is the wrong place to alter this kind of behavior in my opinion.

A Drupal 7 module is basically comprised out of a minimal of two files, a *.info file and a *.module file. The former contains some meta data necessary for Drupal to categorize your module and calculate possible dependencies. The latter contains the actual PHP code.

These files have to be saved in a directory with (preferably) the same name as you named your info and module file. For Drupal to find your module, you can place it under sites/all/modules.

If, for example, you name your module changemyform, these are the minimal required files:

• changemyform.info
• changemyform.module

And both should reside in: sites/all/modules/changemyform.

I suggest you check Drupal's developer's manual for a more detailed explanation about writing modules, including licensing, unit testing, ... . But for this example, the mentioned two files will do.

In your info file you have to at least write the name for the module, a small description, for which core version it is applicable and which dependencies it has. Something like this would suffice for our example:

name = Change my form
description = Changes the submission behavior of my form.
core = 7.x
dependencies[] = webform

Next we should write the logic for the module file itself. The general hook for intercepting any form submission (including a Webform) is:

function mymodule_form_alter( &$form, &$form_state,$form_id ){
  ...
}

With this hook you can, as the name suggests, alter all the forms rendered with Drupal. Not only the submission handler, but add/remove fields, add markup, ... . Replace mymodule with the actual name of your module, in our example case changemyform. Next you need to scope it down to only effect your desired form:

function changemyform_form_alter( &$form, &$form_state,$form_id ){
  if ($form_id == 'my_desired_webform_form_id') {
    $form['#submit'][] = 'changemyform_submit_handler';
  }
}

Notice that I now replace mymodule with changemyform. As you can also see I have added a custom handler to the form's submit property. You will have to write this handler as a function which then will contain all the logic you desire. Thus the total module file now becomes (minus the <?php ?> tags):

function changemyform_form_alter( &$form, &$form_state,$form_id ){
  if ($form_id == 'my_desired_webform_form_id') {
    $form['#submit'][] = 'changemyform_submit_handler';
  }
}

function changemyform_submit_handler($form, &$form_state) {
  ... your submission logic ...
}

Now you are ready to write all the logic you need to capture the data on submit and do as you please.

Since this is a module, you should, of course, enable it in your administration modules overview screen for it to function.

Also (as a nitpick) when writing your own modules, do decorate each function with documentation headers that describe what each function does and what each parameter could hold. Even for tiny, trivial functions.