Closed (fixed)
Project:
Mollom
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
18 Oct 2010 at 06:56 UTC
Updated:
24 Apr 2014 at 17:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
sunAre you using the latest official and recommended releases of Mollom and Webform modules?
Comment #2
amirtaiar commentedYes.
Comment #3
sunSo 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?
Comment #4
amirtaiar commentedYes,
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
Comment #5
sunYou should see something along the lines of the following options:
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.
Comment #6
sunAt 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. :)
Comment #7
sunComment #8
sunMinor variable tweak. Ready to fly for me.
Comment #9
amirtaiar commentedOK,
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?
Comment #10
dries commentedI'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?
Comment #11
sun@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:
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?
Comment #12
dries commentedYou'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.
Comment #13
sunAlright, so here's the code-optimized version of #8. Screenshot:
I'm happy with the patch now.
Comment #14
sunThanks for reporting, reviewing, and testing! Committed to D6.
This improvement will be available in the next official release.
Comment #15
sunPorted to HEAD. Let's see what the bot says.
Comment #16
sunThanks 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.
Comment #17
sun@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.