Webform support
populist - May 17, 2008 - 02:31
| Project: | Mollom |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Description
i installed mollom and got very excited when i saw on the settings page the option to "protect webform form". sadly, this was just to protect the node/add/webform form to create webforms not the actual submissions.
however, with a bit of tinkering i rolled a patch to provide the ability to add mollom stuff to individual webforms. a good next step might be an option to protect all webforms (instead of making you click each one individually).
| Attachment | Size |
|---|---|
| mollom_webform_supporting.patch | 958 bytes |
#1
I have created a patch for webform support in Mollom. The problem with the former patch was that it just did the plain captcha protection and didn't offer the possibility to assign the proper fields of your webform to the proper title/name/mail/body/... submission data of mollom.
With this patch you get an extra tab under the Mollom settings where you can map your webform fields to the data mollom will send as name, mail, body, ...
Only after you have enabled the form there (enable checkbox in its row), your webform will appear under "Spam protection settings" in the general Mollom settings.
I know the interface isn't superb, but it should do the job for now.
Note to Dries and others who wrote this module... Why isn't this module implemented hooked so we can use our own modules to add protection for our own fields? Full Drupal style that is :)
Nevertheless Mollom is awesome ;)
Apply this patch to the latest CVS version.
#2
I have the same issue with protecting webforms. I tried the two patches.
The first didn't had any effect and all submissions went through.
The second produced the following error message on the settings page:
warning: Invalid argument supplied for foreach() in /var/www/vhosts/imagexmedia.com/subdomains/myprogrammer/httpdocs/sites/default/modules/mollom/mollom.module on line 212.
It also showed the CAPTCHA on every form submission, clean text or not, and if the CAPTCHA was entered the form did not submit.
I hope this issue can be resolved soon as the Mollom service is very good and helpful.
#3
Subscribing. Our company would like to standardize on Mollom rather than captcha and this is the issue stopping us. If/when we are able to put resources into adding Mollom support to Webform this thread will be updated.
#4
Subscribing as well...
#5
I rolled another version of the patch which now supports both Webform 1 and Webform 2 and should address the invalid argument problem mentioned in #2 (had to do with the different versions of webform handling their component data structure a bit differently).
I made some improvements to the usability of the settings page to explain what the different fields are, fixed a security issue with some tainted user submitted output, and added a validation form hook to require each webform has at least a body field specified.
While this patch will work (and with some re-factoring and usability improvements could be the sort of thing that could be rolled into the module for real real) I do think the best solution is to create a more flexible framework to allow other modules to hook in and use Mollom's validation.
hook_mollom() anyone?
#6
The next steps I propose here is to (a) create a better way to handle the configuration data about each form. Putting them in the variables table has some performance implications and can be done much cleaner and (b) improve the administrative interface to handle cases where the component title is pretty long and the page will run off the screen and (c) remove the duplication of webform "protect" option since you have to enable on both the main and the webform specific screens.
#7
+1 for this functionality and populist's approach. We expect to be testing this patch within a few days.
benjamin, Agaric Design Collective
#8
Any chance of a patch getting rolled against 6.x-1.5, Ill take a look at this myself anyhow, any advice?
#9
subscribe
#10
subscribing
#11
subscribing
be nice to see this rolled into mollom
#12
subscribe
#13
Hi
How do I use the patch? do I replace the code in mollom.module with that in the patch?
Thanks
Phil
#14
Following. Let me know if any help is needed on the Webform side.
#15
I wonder if we can make this more generic so that it will work with _any_ form, not just webform forms. If not for Drupal 6, we should certainly improve the form API in Drupal 7 to help make this possible. What we'd need is (a) a form registry and (b) the ability to inspect every form in the registry.
#16
Dries, that would be even better. But for now a mollom hook would be great. I think we need to fix this for Drupal 6 now too.
#17
So, we have the maintainers of Mollom and Webform posting, but what now?
This functionality is desperately needed! Webform is almost useless without this... and I can't imagine imposing a CAPTCHA on our prospective clients.
#18
subscribing
#19
It is high on our TODO list. I've also asked Wim Leers to look at this as soon he has some time.
#20
Subscribe for D6 version
#21
Subscribe for D6
#22
I get the following with the patch in comment #5:
Hunk #1 FAILED at 83.
Hunk #2 FAILED at 96.
Hunk #3 succeeded at 206 with fuzz 1 (offset 10 lines).
Hunk #4 FAILED at 711.
Hunk #5 succeeded at 987 with fuzz 1 (offset 238 lines).
Hunk #6 FAILED at 1063.
4 out of 6 hunks FAILED -- saving rejects to file mollom.module.rej
#23
On our site, we put together a little hack for our webforms. We tried to make it general, defining three new hooks so arbitrary forms can use mollom:
hook_mollom_form($form_id): What kind of mollom analysis should be done on this form?
hook_mollom_data(&$form, $form_state, $form_id): Map form data to mollom request data (post_title, post_body, etc)
hook_mollom_form_op($form_id, $form_state): Is this form action a preview, or a submission?
Here's an example of using these hooks in a custom module.
<?php
function example_mollom_form($form_id) {
if ($form_id == 'webform_client_form_1') {
return array('mode' => MOLLOM_MODE_ANALYSIS);
}
return array();
}
function example_mollom_data(&$form, $form_state, $form_id) {
$data = array();
if ($form_id == 'webform_client_form_1') {
global $user;
$values = $form_state['values'];
$webform = $values['submitted'];
$data = array(
'post_title' => $webform['subject'],
'post_body' => $webform['content'],
'author_name' => isset($user->name) ? $user->name : NULL,
'author_mail' => isset($user->mail) ? $user->mail : NULL,
'author_url' => NULL,
'author_openid' => isset($user->uid) ? _mollom_get_openid($user) : NULL,
'author_id' => $user->uid > 0 ? $user->uid : NULL,
'author_ip' => isset($values['nid']) ? NULL : ip_address(),
);
}
return $data;
?>
This is by no means perfect! Some of the caveats:
I'm mostly just throwing this out for comments on the hook structure--do people like this as a way to extend mollom?
#24
For what it's worth, I've been using Populist's #5 patch successfully so far.
#25
I'm subscribing to this one too. Also need to figure out how to test patch, etc. so I can help out. BTW, love Mollom and have it working now on a Drupal 5 & 6 site in active use. Other than the Webforms in use on those sites, Mollom is working great in blocking spam...
#26
Just to confirm that the patch by evolvingweb-vasi has been working very well for us.
Before getting Mollom setup with our webforms, I was getting 10 junk submissions a day being sent to my Blackberry.
It occurred to me that once people start submitting things other than comments to mollom for analysis, data privacy becomes an issue. Does Mollom's EULA say anything about this?
#27
Why cant any of you reply and say how to use the patch. It is precisely this sort of unhelpfulness that makes Drupal hard to get to grips with. Perhaps it is obvious to you what to do with the patch but it is not for me.
Please can someone respond with a little helpful comment.
#28
@AlpesInfo: there is plenty of helpful documentation about patching here - http://drupal.org/patch/apply
#29
Subscribe for D6 version
#30
Sorry to drop out of sight for a while, but I was diagnosed with breast cancer in October and its been no end of fun and games ever since! Recovering from surgery at the moment, and it appears (crossing fingers) as though all the cancer is gone. I'll know more after I see the cancer doctor later this month...
In any case, getting back to this subject I'm really confused! Appreciate the reminder link from Rowanw on how to test patches:
http://drupal.org/patch/apply
As this subject started with a post by populist back in May, with the cited version being Mollom v:5.x-1.3, can I assume all of these patches in this thread are for the Drupal 5, Mollom module?
Then there's the confusion over which patch to test.
The thread start was by populist
Comment #1 by Davy Van Den Bremt has an update for that patch
Comment #5 by populist has a newer patch to fix issues mentioned in #1
Comment #23 by evolvingweb-vasi has yet another patch with something on the hook implementation (on which I'm rather lost!)
Bottom line is that I see two different patches that need testing. The one in Comment #5, and the one in Comment #23. If I'm wrong on this assessment, please correct me! My plan is to test both of these out - separately - on a development install here.
#31
In Mollom 6.x-1.6, I have a checkbox for "Protect Webform forms." Is it safe to assume that Mollom does support Webform for D6 now?
#32
@Irene Kraus,
Yes evolvingweb-vasi's patch in #23 is an entirely separate idea, based on providing hooks. It's based on Drupal 6.6
Feel free to call or email me if you need any clarification about what evolvingweb-vasi is doing.
All our contact info is at this page: http://evolvingweb.ca/contact-us
I wish you a speedy recovery!
@pcorbett,
No, unless you use the patch in #23. It's been working great for us. Out of the box, Mollom can protect the "Add a new Webform" node creation form.
Yes, it's quite misleading!
#33
Does anyone have a Drupal 6 version of the patch?
#34
I manually applied the code in the patch for 5x to my 6x installation, and it adds the fields but on submission I get the following error:
Fatal error: [] operator not supported for strings in C:\testingserver\pixelclever\sites\all\modules\mollom\mollom.module on line 274
#35
It turns out the problem was caused because webform sends the body as a string rather than an array. I created this patch for Drupal 6 which does a check to see if the submission is coming from webform and if so add the link with .= instead of [].
Now all works well for me.Just to clarify, this patch is for Drupal 6 against Mollom 1.6
Update: There are some problems with this patch. Mollom is shown at all times rather than only when a suspect spam is sent and also the audio captcha doesn't work.
#36
subscribing for D6
#37
Is this still in progress? It's critical for us to have. We will subsidize the development of a patch, if there is a qualified developer out there who would create it but cannot afford to make time to do so.
#38
subscribing for D6
#39
Subscribe
#40
Subscribe
#41
@Digital Deployment: we plan to add this to Mollom 1.7 (next release) but we could use some help. We haven't started the work yet, but can broker this work.
#42
I've been meaning to find time to test out the Drupal 5.x patch, but found out I had to undergo chemo treatments for the breast cancer. Not been feeling too hot!
Have gotten the TortoiseCVS mentioned on the page below for testing within a Windows system downloaded from here:
http://drupal.org/node/60179
Was going to take a shot at doing that later this week, if my eyes will cooperate so I can read. I've never worked with CVS before, and haven't had any luck in finding a 'beginner' tutorial on working that out. 'Course, I plan to test on a development install here first, just to confirm no impact on anything else on live site before it heads there. Was also planning on taking some screen shots and so-forth as I do, which could be used to supplement your documentation for that area. (To help out folks like me!)
Sorry if anyone's been holding their breath on me!
#43
Running the patch and it invokes, but mollum admin buttons do not appear on webform submissions-- not sure how easy that would be because they are not stored as nodes. This, however, makes it difficult to report spam treated as ham, as spam. FWIW. Thanks.
#44
@Irene
There is no need to be sorry...
Life has it's priorities, and yours is nothing but your recovery.
Warm regards from sunny México!
:-)
Pepe
#45
@Irene,
Ditto #44. Best wishes for your recovery.
Ken
#46
Subscribing.
#47
I rerolled my patch from #5 to patch against the latest webform version 1.7 for Drupal 5. I think the better solution here is to provide general hookability for Mollom to secure any Drupal form, but in the meantime here is a possible solution.
#48
@Dries: any change this will be available for D6 1.8? If so, is there a date set for this release?
@All: Does someone has a working patch for D6 1.7, I have Captcha working for the moment based on #35 but I rather have the text analysis :p
#49
Subscribing for D6 1.7
#50
I'd like to add support for webforms to the next Mollom release for Drupal 6. I won't have the cycles to work on this until after DrupalCon DC but if a patch emerges, I'd probably be able to roll a new release. Any help for D6 is appreciated. Thanks.
#51
Patch from #47, adapted for 6.x-1.7 with some minor changes to the validation of the mollom-webform-settings form. I'm new to this, so use with caution, if at all.
#52
@Dries - could we setup a bounty? I noticed the bounty module and the donorge site are abandoned. I would chip in. Any recommendations for how we do this?
#53
subscribe
#54
#51 worked for Drupal 6, thank you smautf and populist.
#55
Moving version.
#56
#51 seems to work for me. Will watch it and see.
One gui hiccup though: using a fixed width theme, the webform component selection extends way off my main content under the right sidebar. This seems partly due to the popup menus auto-sizing to all to fit the largest text in that form.
For example - of 3 fields named Name, Email, and A Very Long Name That Causes The Problem. The 3rd field makes the first two popup menus size to its width and making the whole display wider than need be.
However, even without that very wide field, the 5 columns tend to be too wide for my (and probably many) fixed width themes.
#57
You're right about the GUI problem - using this with a fixed width 960px theme with two sidebars looks terrible in most cases. If it extends under the right sidebar, where you may have text or other blocks, you could loose some functionality.
#58
See also #412760: User interface brainstorming for some UI brainstorming that would assist with Webform integration.
#59
Subscribing
#60
Subscribing too
#61
My workaround for hidden columns was to only show the first 15 characters of the longer fields, which is achieved by replacing
$components[$component['form_key']] = $component['name'];with
$components[$component['form_key']] = drupal_strlen($component['name']) > 15 ? substr($component['name'], 0, 15).'...' : $component['name'];in mollom_webform_settings().
It's a hack but at least I can see the columns now.
#62
subcribing
#63
What about webforms where there is no real 'body' field? For example, we have some forms which are used for registrations, and contain name, URL, email, etc, but no textarea-like fields. The patch should contain some guidelines as to what to do in that case in the help text.
#64
@deviantintegral - For some types of forms, it would be very difficult for Mollom to decipher what is spam vs. ham due to the lack of written content. For these cases, Mollom integration could simply be on or off (ie. show the captcha on this form 100% of the time). If it would make implementation simpler, perhaps this is what initial Mollom integration could look like?
#65
Yeah, that might be the way to go. I have mollom enabled for these forms mainly because we're getting hit with bots filling in completely random characters. But if they ever get smarter, I can see us having to move to captcha-enforced down the line.
#66
subscribing.
#67
Subscribing
#68
I tried the patch for 5.17 but it doesn't appear to be working. I can see it webform in the mollom settings but when I do a submission it doesn't block it.
#69
#70
Just a note after one year of this issue: the better, more complete, more Drupal and perhaps faster solution would be integration with CAPTCHA API.
#71
The difference is that mollom only kicks in if it thinks the content is a spam, captcha is allways on. The biggest problem is that mollom doesn't really know how to interpret each field.
#72
The patch from #51 seems to work, except that when I get a webform submission that is spam that Mollom let through, the link to 'report as inappropriate' takes me to an 'access denied' page... I can't find anywhere else to let Mollom know this submission is spam...
Can anyone else confirm this?
#73
@BWPanda:
I had the same problem. The fault lay in mollom_menu() in the definition for the contact form:
$items['mollom/contact'] = array('title' => 'Report and delete',
'page callback' => 'drupal_get_form',
'page arguments' => array('mollom_report_contact'),
'access arguments' => array(TRUE), // Everyone can report contact form feedback.
'type' => MENU_CALLBACK,
The 'access arguments' value -- TRUE -- simply didn't work. Changing it to 'access content' did the trick for me.
'access arguments' => array('access content'), // Everyone can report contact form feedback.#74
@baroquem: Thanks for finding that bug. I filed a patch in #486798: Fix 'access arguments' to 'access callback' in mollom_menu().
#75
I just committed #486798: Fix 'access arguments' to 'access callback' in mollom_menu() to the Drupal 6 development branch. Thanks baroquem and Dave Reid.
#76
subscribing
#77
Now that that bug's been fixed, we can mark #51's patch as RTBC.
#78
Subscribing.
#79
I applied patch #51 with Mollom 1.9 it seems to only work when the webform settings are on "CAPTCHA only" and not "Text analysis with CAPTCHA backup".
#80
A hook_mollom is the right way to do this. A lot of the work here IMO should be done by the webform module.
Hook discussion is at #245682: Enable use of Mollom for any form I made some notes here as well
#81
I've installed Mollom 6.x-1.9 and the patch in #51. It seems to be working with no problems, though I don't know how to test a form actually getting spammed.
Thanks for all the work. Looking forward to something like this being incorporated into the module.
#82
I don't think this webform support method will ever be incorporated into the module - as pointed out by johnskulski, #245682: Enable use of Mollom for any form, or any other more general approach, would be preferred. We shouldn't need to patch mollom for every type of form out there.
The patch in #51 should work when applied to Mollom 6.x-1.7, but it will never serve as anything more than a temporary fix.
#83
Need this feature request. Subscribing.
#84
This seems to be taking forever. I appreciate that this is a complicated issue and Mollom is a complicated module, but while we're all waiting for a universal 'Mollom can handle any form' solution, it makes sense to me to enable Mollom to protect webforms, and this functionality can later be removed and replaced with the catch-all functionality.
Here is the patch from #51 rolled against Mollom 6.x-1.9. I hope this works ok for you.
#85
Patch in #84 applies cleanly and works for me.
+1
Sick of maintaining a sites/all/patches directory. Sigh.
#86
subscribe
#87
Does anyone know if the patch in #84 will also work on Mollom 6.x-1.10?
#88
The patch in #84 does not work with 6.x-1.10
#89
OK, I downgraded the Mollom installation on the site I've been having trouble with webform spam on back to 6.x-1.9 and applied the patch in #84, but it doesn't appear to have done anything. I don't see any new options in Mollom's configuration screen, and when I view any of the spammy webform submissions I've been getting, I don't see any "report to Mollom" link or anything like that.
Should there be any visible changes from applying the patch? Or is it supposed to just protect the webforms "behind the scenes" somehow, without anything being visible unless someone does submit spam?
I considered testing it by copying and pasting the text of one of the spam submissions into a new submission, but I don't want Mollom to start thinking I'm a spammer... Is there any other way to tell if it's doing anything?
Edited to add: apparently it isn't. The client tells me the spam is still coming in. So this patch doesn't appear to work even on version 6.x-1.9, never mind 6.x-1.10. :-(
#90
@spidersilk
If I recall correctly there should be some extra settings you need to configure for that patch. Look for a new tab (?) in the Mollom configuration page, what you need to do is tell Mollom how to interpret each webform field.
Also, check out the Mollom developer documentation for instructions on how to test if Mollom is working.
#91
I apologize if this has already been mentioned, or if it's the wrong forum:
Mollom seems to be working great on my sites with webforms, but I've noticed it doesn't seem to protect Webform Blocks.
I just thought it would be worth a mention.
#92
Does anyone have a working patch for mollom 6.x-1.10?
#93
Temporarily marking critical to get maintainer's attention. This has been sitting here forever. We shouldn't need to reroll again for the current Mollom version after we've rerolled 3 or 4 times already, so I'm leaving at RTBC.
#94
@mcrittenden: That's not what the priority is for.
In fact, we don't currently have a working patch (based on the reports since 6.x-1.10 released), so I'll fix that as well.
#95
@ScoutBaker: I know what the priority is for, and I also know what the issue queue is for but when the issue queue isn't used properly (i.e., working patches are ignored for months) then IMHO we can use the priority improperly as well. After all, we have to get maintainers' attention somehow.
But, since Dries has said he wants to go the "works for any form route" and since Dave Reid just announced in #245682: Enable use of Mollom for any form that he's going to be working on it ASAP, I'm going to mark this as dupe in favor of #245682: Enable use of Mollom for any form
#96
A patch to enable mollom to be used on any form is a long way off. People can get the benefit of webform integration right now. I would certainly not call this a duplicate of the other issue and I urge you to do the same. We could be months away from allowing mollom to be used on any form but with a simple reroll, this patch will be working with today's version of mollom.
#97
We are not months away. I hadn't been able to devote as much time to the proper approach for this problem since I've been a co-maintainer of this module, and for that I apologize to everyone in this issue and to Dries. However, I'm determined to get this finished *properly* by the end of the week.
#98
@timhobert: The setting on the Mollom configuration page for webforms is to protect the form that you use to create a webform.
#99
Patch from #84 adjusted for 1.10. Seems to work so not sure why it's been a month.
#100
The function mollom_mail_alter was changed from release 6.x-1.9 to 6.x-1.10. It now only adds the 'report as inappropriate' link to a subset of the e-mails. The attached patch for mollom version 6.x-1.10 is a full patch that also adds the webform_submission e-mails to the list in mollom_mail_alter.
#101
#245682: Enable use of Mollom for any form is currently up for review, and (assuming no major bugs) it'd be better to just get the other issue done it seems.
#102
Agreed with #101 is the way to go.
However, the original patch that @populist made was deployed on a live site and we needed to re-roll the patch for 5.x-1.8. Maybe someone else could use it.
#103
Anyone experience any issues with the Webform update to 6.x-2.8 and the above patch in comment #100?
#104
Have we reached relative consensus that the Mollum support for any form is the way to go?
#105
@kenthomas: Yes this issue has already been marked a duplicate of the general form solution. If anyone needs this now, they can apply the patches provided by peers themselves, but warning that it might not upgrade to the any-form code.