Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I noticed in use with the latest webform module with D6, text analysis is not working properly. Non spammy post (legit people) are still being required to input captcha every time. Never had a problem until both modules were updated last week.
No notices found in log.
Webform 6.x-3.11
Drupal 6.22
PHP 5.3.6 (built on enterprise linux 5.5)
Comments
Comment #1
sunWe'd need the Mollom session information for an incorrectly identified post, as returned by the Mollom servers, to investigate why a specific post was blocked or not. At minimum, we need the Mollom session ID/hash (a string of 32 letters and numbers). This should normally be stored in the logs of your site.
See http://mollom.com/faq/reporting-ham-incorrectly-blocked-by-mollom for more information
Can you look in the "mollom" category of your Drupal logs on Admin » Reports » "Recent log messages" to see if you have a log entry that includes a Mollom session ID for the post you're concerned about?
If you cannot find this information in your logs, then this may mean that you are running an older/outdated Mollom client. If you do not find the log messages page in Drupal, please check your user permissions, or alternatively, make sure that the "Database logging" module is installed.
Comment #2
jnettikI'm getting the same thing. It is always flagging my content.
The things it seems unsure about is my name, email address and phone number. Is there anyway to have this not be so strict?
Comment #3
sunmmm, these values should not have been part of the post_body:
What kind of form are you protecting there?
Comment #4
jnettikIt's just a simple contact form. James is a simple textfield for name and the second is an email field. There is another textfield there for a phone number that I removed as well.
Comment #5
sunCan you clarify with which module (and version) you have built that contact form?
Comment #6
jnettikWebform 6.x-3.11.
Comment #7
tkasis CreditAttribution: tkasis commentedI am having the same issue. All submissions flagged as "Unsure".
Mollom 6.x-1.16
Webform 6.x-3.11
This is how my form is built, Contact Us.
Name textfield -
E-mail email -
Subject textfield -
Message textarea -
I see what you mean by the weirdness of everything wrapped in post_body.
Has there been any resolution on this issue? Do you need any other information?
Comment #8
aspedia CreditAttribution: aspedia commentedWe've also been seeing the same thing on 6.x-1.16 and webform 6.x-3.11.
Comment #9
sunBetter title.
Comment #10
tkasis CreditAttribution: tkasis commentedPlease clarify what you mean by "Better title".
Never mind. I see it now.
Comment #11
sunComment #12
tkasis CreditAttribution: tkasis commentedI noticed the same reaction on these two forms. I was required to recognize text, as a second step, on seemingly non-spammy submissions.
http://www.sooperthemes.com/contact
http://tomkraftdesign.com/contact
Do you think it might be somehow triggered by my name "Tom Kraft" or email address?
Comment #13
Encarte CreditAttribution: Encarte commentedSubscribing
Comment #14
arpieb CreditAttribution: arpieb commentedWe're seeing the same thing in the following environment:
From what I see, it appears that Webform + Mollom are packing all the form fields selected under Text fields to analyze on the Mollom form configuration page into the Mollom API's post_body field as there appears to be no other way to map Webform elements to any other fields for the checkContent Mollom API call.
The only way around this appears to remove the fields in question from text analysis so only textfields and textareas that contain "content" are passed to Mollom for analysis, short of the Mollom API being updated to allow one or more post_body-like fields to be passed, each flagged as certain types (i.e. email, URL, numeric, alphanumeric, etc).
I supposed the Mollom module could be modified to execute checkContent queries against each field, but that might seriously chew through an account's allocation depending on how the Mollom system handles the set of queries in its accounting system...
Comment #15
sunI tested this with the latest 2.x release and was not able to reproduce this anymore.