Add submission API hooks

I agree. I needed this functionality for something I was working on so I added it.

Here is the patch. It suits my needs, but might need more robust testing.

to use the hook create a function:
your_module_webformsubmission($op, $node, $submission) {
}

Hi All,
I'm using webform in many projects here (just this month we already deployed 4 websites using webform module) and a more flexible form_handler and a Webform API are things frequently requested by my coders.
But, given my experience with CAPTCHA I know that a bad designed API is worst than no API at all.
I would apreciate if we could start a discussion here about how to flexibilize Webform before writing patches.
Disassociation Webform from the survey approach (having webforms that do not save data in the db for example) would be my first goal.
What do you think guys?

Quicksketch?

I've got mixed feelings about putting APIs into Webform. The complete lack of APIs is intentional on my part, because I don't want people using Webform when they should be using CCK or nodes. Webform generally is not a über-well designed piece of software, and tacking on an API at this point would encourage development on a shaky foundation. Some of these things that make me very nervous: the database storage mechanism, submission handling of two structures ($form_values['submitted'] and $form_values['submitted_data']), and dealing with multi-page forms.

To ease my concerns, what would be the intended purpose of leveraging Webform if it did have such an API that let you intercept submissions?

I'd like to give a +1 to an API - in my own dealings with drupal, I've run into two cases where a true API would be helpful:

1) Signup module (build a custom form rather than the built-in) #29568: Flexible number and type of fields
2) Salesforce Webform Submission module (goes with this sub-module idea proposed in the issue title) - http://www.drupal.org/project/salesforcewebform

Both of these could use an API to hook into Webform with - right now, I accomplish #2 by calling the module inside the 'Additional Processing' field of the webform, then pull the data out of $form_values. With an API, it could be done without the code in the 'Additional Processing' field.

Bryan O'Shea
Obsidian Design
Dublin, Ohio

Another vote for an API here. Our requirements are similar to obsidiandesign's. Webform submissions need to be posted to Hubspot. At the moment I'm using hook_form_alter to intercept submissions, and although it is working it doesn't seem like the most elegant solution and isn't really the intended purpose of hook_form_alter as I understand it.

Another place where I need to intercept at the moment is when form components are added/edited. Hubspot's form naming convention does not fit with webforms (they use camel case), so fields that are posted to Hubspot need a hubspot specific name. At the moment I intercept 'webform_component_edit_form', but this also relies on (mis-)using hook_form_alter.

I wrote a patch very similar to aaron1234nz. I opted to call the hook webformapi instead of webformsubmission. But what is in a name ;)

My use of the hook is to capture a submission and to push it into a third party CRM table. A users who are a member of a scheme we run can input data they capture from their day-to-day activities, and we aggregate it.

For me an alternative would be to use hook_cron to find new submissions and to then push them to the CRM table.

I commited a new webform integration project (webform2sugar) and it uses the patch as well. It would be more user friendly if users don't have to patch their webform.
So another vote for this patch to be included in the next release.

Sorry double post.. please remove this :)

+1 for a new hooks, while using hood_form_alter and adding a custom submit function works, its not very straightforward. Integration code would be easier to maintain if there were explicitly named hooks to keep track of instead.

I'm moving this to 3.x, no new features are being added to 2.x.

Here are the hooks I think we should add, mostly using nodeapi as a template:

- hook_webform_submission_presave($node, $submission) (before any insert or update)
- hook_webform_submission_insert($node, $submission) (after inserts)
- hook_webform_submission_update($node, $submission) (after updates)
- hook_webform_submission_load($node, $submission) (after load)

To closely align with Drupal 7, the load hook should be an array of submissions, keyed by SID, especially considering the additional work that might be necessary when showing a listing of submissions. All hooks should be able to modify submissions as a pass-by-reference array, though it would only make a difference in presave and load.

Note that we're fairly close to getting a consistent data structure with the $submission variable, which is a flat, keyed-by-cid array of data, rather than the $form_state with a tree structure. It certainly makes looping a lot easier, though I have a feeling it might cause some trouble for people that reference items by their form_key name.

Of course we should also add:

- hook_webform_submission_delete($node, $submission)

I've committed the attached patch which adds all the hooks described above, plus some additional documentation in the webform_hooks.php file for future reference.

And how can you change some values before sending emails ?