Is there a way to make this module work for webform submissions?

Did you ever find a solution??

I'm having the same problem and looking for a module to control spam submissions.

Thanks, Joe

What are you using to create the webforms?

Any module could implement the Spam API to get its desired content passed through the spam filters. Alternatively, a separate custom submodule for Spam (also using the API) could provide such functionality.

I'm sure we'd be happy to see code for such a thing submitted, either way. We encourage third-party use of our API to hook into the spam engine.

gnassar,

They are most certainly talking about the webform project. I would also like to have that feature as I do use webforms all over the place to gather data from my readers, customers, etc.

This being said, to the minimum it should be a sub-module, it could also be a separate Spam Webform module that implements the different hooks as having a sub-module also means having to maintain it as part of the spam module... 8-)

This is otherwise very similar to a node with many fields instead of just a title and a body.

Thank you.
Alexis

That's what I figured -- wanted confirmation from them, though; wouldn't be the first time I've seen handmade webforms.

I meant "submodule" in the sense that it would be using the Spam API. I think we're saying the same thing. It would be (by my nomenclature) a contributed submodule, not one that is native to Spam.

But long story short -- yes, again, we'll be happy to see code on this. It should be very possible.

Support for the webform module would be added by adding the appropriate include file in content/, I'd expect. So long as one of the spam module maintainers is willing to maintain this include file, it can be included in the core spam module project. If not, then it would need to be maintained in an external project.

You mean in content/, right?

IMHO I think we should probably keep our support limited to core content modules only; third-party modules should have separate spam contrib modules. Doesn't mean we can't maintain/support it -- just that it shouldn't be in core spam.

> You mean in content/, right?

Whoops, yeah. I went ahead and updated my previous comment to try and minimize future confusion from this.

> IMHO I think we should probably keep our support limited to core
> content modules only; third-party modules should have separate
> spam contrib modules. Doesn't mean we can't maintain/support it
> -- just that it shouldn't be in core spam.

I have mixed emotions on this. On one hand, it simplifies things for the end user if we include support for both core and contrib modules. On the other hand, trying to keep up with contrib modules is quite a bit different than keeping up with core, as contrib modules may decide to change their APIs more frequently, etc. So, either we should start a spam_contrib project which is a potpourri of contrib api implementations for the Spam module, or we should just go ahead and maintain this within the core spam module.

The fact that there is not a wealth of spam_contrib include files written suggests to me that creating a spam_contrib project is overkill at this point... perhaps we should include this with the main spam module for now, and consider splitting it out into another project at a future time should we end up with support for several contrib modules.

The third option: someone else should maintain it, still makes more sense to me.

We have enough on our plates maintaining what we have in front of us. We have feature requests that we haven't touched in quite a while, and we have an imminent move to 7. That's why we've usually requested that all the other requests for supporting other modules be rolled separately (and we've had a few, as you'll recall, including many new filter requests).

I agree that spam_contrib is overkill right now -- but anyone that can contribute a module for us to maintain can also contribute that module to drupal_contrib and maintain it themselves. And then we avoid the whole problem of tracking a second (third, fourth...) third-party contrib module's API changes.

Note that we were just talking about the CCK problem. Obviously, the fact that the fields don't get saved is something we need to fix in Spam, but supported the CCK fields would otherwise require us to also have another level of hooks since those are part of nodes (content/spam_content_node.inc). This being said, you may already have such.

One idea that popped to my head was the concept that all fields should be added to the buffer to be checked by all the filters with a prefix. So for instance, when we check a node we would end up with something like this:

Title: My Spam Node
Body: This is total crappy spammy content
CCK Link: http://www.example.com

That way the filters can react to a specific field. Unless it is possible to pass multiple strings (probably cleaner) then you could offer the user a list of all the available strings and how to test them.

Just an idea. 8-)

Thank you.
Alexis

Alexis,
I think you may have posted that comment in the wrong issue?
If not, I'm not sure I understand.

gnassar,

Jeremy was talking about adding a content for webform. We could do the same for CCK...

Although the problem with CCK is that it is attached to nodes.

But I still think it should be in a 3rd party module and not in the spam module (i.e. spam_extensions or spam_contrib).

Thank you.
Alexis

Got it. Thank you, Alexis.

> The third option: someone else should maintain it, still makes more sense to me.

I still think this should be included with the core spam module for 2 reasons. 1) there isn't anyone else contributing/maintaining this code right now, and 2) while webforms are not in core, the webform module is one of the top 10 most installed contrib modules.

In any case, the discussion is a mute point until code is written.

I didn't realize it was that popular. That does change my perspective a bit.

Even so, if somebody were to contribute that code, I'd expect that they'd also stick around to support it -- and if they're doing that, it's basically in a separate module anyway. The only distinction is whether they'd be making a separate project for it or not.

As an example: Views, of course the most popular contrib module, supports all core content types but does not support webforms.

Like you said, it's moot until we get code, but even so I hope it stays as a separate module.

In fact, perhaps at that point we can submit a patch to webform to roll in spam API support -- that's really what we wanted folks to do anyway, obviously, seeing as we included core content support as .inc files instead of making them modules. That may be the best way to go about this.

> Views, of course the most popular contrib module,
> supports all core content types but does not support webforms

This is on purpose, however. Webforms are not nodes. If you need nodes, you'd build them with CCK...

A webform is a specialized node with... a form (for end users to fill out.)

In a way, it is similar to CCK, except that CCK can be attached to any node whereas webforms has that specific node type. Plus, CCK is filled by the node editor to add content to the node, whereas webform gives the reader a way to submit a form created by the editor. The submissions are tracked on a per node basis.

One thing about webform development though... D6 is pretty much closed. They really only offer "real" bug patches, it changes very very little. I would be really surprised they'd accept anything like this directly in their module.

Now, I do use webform (and CCK) and have the Spam problem too. So I may very well submit code at some point... 8-) At this point, I hard coded tests for stupid emails that I do not want to receive. That's a bit unpractical though.

There is an example: http://www.m2osw.com/trinity_register

Thank you.
Alexis Wilke

Hi guys, just hopping in here to test the waters of Spam module. I've never used Spam myself, but I'm reviewing it for one of my projects. For my purposes, I'm looking for spam analysis specifically of webform data more than anything else, so this issue of interest to me.

One thing about webform development though... D6 is pretty much closed. They really only offer "real" bug patches, it changes very very little. I would be really surprised they'd accept anything like this directly in their module.

That's true that the Webform 6.x-2.x branch was bug fixes only, but I'm still maintaining the Webform 6.x-3.x branch in parallel with 7.x-3.x, so it's still getting new features all the time. That said, I'd really prefer to keep integration with Spam module separate from the project itself. If the Spam project includes the integration, I'd be happy to help with the support of it.

Right now this is all a bit moot because we need a D7 port of Spam, so I might start by helping out with #1063524: Port spam module to Drupal 7 if I get a chance.

I am closing this issue, since it's for a Drupal version no longer supported.