I have create a mollom form for protecting my Webform.
I choose the captcha option.
When entering the webform as anonymous user I can't see the capthca and I keep getting spams from this Webform.

Comments

sun’s picture

Are you using the latest official and recommended releases of Mollom and Webform modules?

amirtaiar’s picture

Yes.

sun’s picture

Version: 6.x-1.9 » 6.x-1.14
Status: Active » Postponed (maintainer needs more info)

So it seems you're using 6.x-1.14.

1) Is it possible that you protected the Webform node form, instead of the Webform submission form?

2) Is that webform publicly accessible? If so, could you post a link to the webform in question?

amirtaiar’s picture

Yes,
1/ Can't understand the different. In mollom settings >> add form I have chosen the "webform form" - no option like you sugest here. Or maybe I ma missing somthing.
2/ Here is a link - http://www.galil-home.co.il/en/form/contact-us
Thank you

sun’s picture

StatusFileSize
new3.73 KB

You should see something along the lines of the following options:

mollom-webform.png

The entry that is prefixed with "Node:" protects the Webform node form only, which is normally used by site administrators only.

The entry that is prefixed with "Webform:" protects the actual Webform submission form; i.e., the webform that your site visitors fill out.

If the second entry does not appear for you in the select list, then this likely means that either the webform is protected already (and listed on Mollom's overview page), or it is not yet visible to Mollom -- in the latter case, try whether flushing all caches helps.

sun’s picture

Title: active mollom on webform - not working » Webform protection not working
Version: 6.x-1.14 » 6.x-1.x-dev
Component: Miscellaneous » User interface
Category: task » bug
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new1.53 KB

At the very least, we can improve the overview page and also prefix the form titles with their corresponding module names (like in the "Add form" options visible in the screenshot). Actually, I always wanted to do that, so this is the perfect time and issue to finally do it. :)

sun’s picture

sun’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new1.53 KB

Minor variable tweak. Ready to fly for me.

amirtaiar’s picture

OK,
So, I can't see the "webform: ..." - Try flash cache and nothing.
I am getting spams so it can't be protected I guess.
Any ather suggestions?

dries’s picture

I'd do "Form name (Module name)" instead of "Module name: form name".

1. Not everyone might be familiar with modules. For example, on Drupal Gardens, users might have never seen the module pages. Leading with the module name is valuable for developers, leading with the form name is valuable for moderators (who don't necessarily know about modules).

2. It is also consistent with how we display "(Discard)" and "(Retain)" in the other column. I think it is visually more appealing.

Can we give that a try please?

sun’s picture

StatusFileSize
new41.75 KB

@amirtaiar: Not sure what's going wrong for you. If there is no entry for your "Contact us" webform submission form, then the Webform module is not letting Mollom know that the webform exists. Since you already flushed caches, the only other option I can think of is that you may have the latest version of Webform 2.x, but you need Webform 3.x; i.e., the latest recommended Webform release for D6 that can be downloaded on http://drupal.org/project/webform. Webform introduced support for Mollom in its 3.2 release, the current release is 3.4. Can you double-check that once more?

@Dries: I've tried that now, screenshot:

mollom-admin-parenthesis.png

I'm not convinced that putting the module name behind the form title really improves the situation. The primary user interface interaction of this overview page, as well as the select box on the "Add form" page, is to find a certain form among many, so as to be able to add a protection for it, or change or remove the existing.

Therefore, the question is how to present a potentially large list of entries in a way that a user can quickly find the entry he's looking for. This is commonly solved by two basic techniques: (i) sorting (ii) grouping.

To find the proper sorting and grouping algorithm, we need to ask what the primary workflow of a user is, and I think that's:

1) Create a new entity or bundle elsewhere; e.g., either by creating a new content type or webform, or by enabling a module.

2) Figure out that 1) led to a public form that needs to be protected.

3) Go to Mollom's admin page to make sure that 1) is protected.

Now, a site builder, as well as someone who is only slightly familiar with how Drupal works, will immediately associate the task he did in 1) with a certain module. Therefore, grouping and sorting the forms by module vastly helps the user to find the form he is looking for.

But, as you say, a user, who is not familiar with anything when it comes to modules, might not be able to understand the meaning of the module names. The user is most likely rather mapping the forms to "groups", which relate to the "task" he just performed, guided by the rest of Drupal's administrative interface texts. In this example, he's going to scan the list for the respective names he knows from the primary task he did in 1) (e.g., "Content [type]" or "Webform"). To properly accommodate for that, we'd have to introduce a 'group' key for hook_mollom_form_list().

However, due to Drupal's modular nature, most modules are sufficiently denoting a "group" already. In fact, I'd say that we can do #7/#8, but additionally account for the module name confusion by merely hard-coding an exception for the "Node" module, which should appear as "Content" (or "Content type") instead.

Thoughts?

dries’s picture

You're right. The screenshot in #11 convinced me. Thanks for giving it a try -- that was really helpful. I recommend we go ahead with #8.

sun’s picture

Alright, so here's the code-optimized version of #8. Screenshot:

mollom-admin-13.png

I'm happy with the patch now.

sun’s picture

Title: Webform protection not working » Ambiguous form labels in lists of protectable forms
Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Thanks for reporting, reviewing, and testing! Committed to D6.

This improvement will be available in the next official release.

sun’s picture

Status: Patch (to be ported) » Needs review
StatusFileSize
new4.07 KB

Ported to HEAD. Let's see what the bot says.

sun’s picture

Status: Needs review » Fixed

Thanks for reporting, reviewing, and testing! Committed to HEAD.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

sun’s picture

@amirtaiar: I hope you've seen my reply in #11. Feel free to re-open this issue if you are still not able to protect the webform submission form after double-checking that you are using Webform 3.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit e3094ec on master, fai6, 8.x-2.x, fbajs, actions by sun:
    #944602 by sun: Fixed ambiguous form labels in lists of protectable...

  • Commit e3094ec on master, fai6, 8.x-2.x, fbajs, actions by sun:
    #944602 by sun: Fixed ambiguous form labels in lists of protectable...