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.
Currently the D7 version installs and enables protection for all possible forms on install. This functionality is contrary to the standard behavior of letting the user figure out what they want configured.
Comment | File | Size | Author |
---|---|---|---|
#11 | mollom-HEAD.node-default.patch | 765 bytes | sun |
#1 | 672788-mollom-D7.patch | 1.42 KB | Dave Reid |
Comments
Comment #1
Dave ReidComment #2
Dries CreditAttribution: Dries commentedI think the current behavior is OK, so I'm not 100% convinced we need this patch. Happy to discuss it though.
Comment #3
Dave Reid1. We don't do this in the D6 version.
2. Users have protection enabled for all forms, no keys entered and the fallback behavior is the block all submissions. So users enable the module, don't configure it, and all submissions are blocked. That's not a good default behavior.
Comment #4
sunI disagree as well. :)
What we really want and need is to add a configuration healthiness state tracking system variable, which globally disables Mollom in case the global configuration settings are not properly setup (yet). I'm working on that already.
Regarding this issue, I'd agree with removing the auto-protection for node forms. Therefore, I think we'd get the same behavior as previously - Contact + User + Comment forms are protected by default, but node forms not.
Comment #5
Dave ReidIf I'm not in the majority, eh, not much I can do.
I just think this pattern of 'apply everywhere' (opt-out) is just very odd and not really done anywhere else. We don't add permissions for every single role when modules are enabled (expect for adminrole, but that's an exception), we don't add all possible fields on all content types when a new field module is enabled. It's perfectly acceptable for users to need to configure and set-up a module after enabling. If I have an install profile that just wants to enable Mollom protection for one form, I have to go in and delete more things instead of enabling what I wanted.
Comment #6
sunSure, but I'd say that this case is a bit different. You are installing Mollom for the sole purpose of protecting your forms from spam submissions. Contrary to the other modules you listed, the Mollom module already knows where it can apply itself, and, it's very very likely that, if it wouldn't auto-apply itself, you would manually protect those forms.
So the idea is to simplify the initial installation process, and find reasonable defaults that make sense for the 80% use-case. ;)
Comment #7
Dave ReidBoth sides don't have any data to back it up, but sounds like this is a won't fix.
Comment #8
sunerrr, actually I would agree with not protecting node forms by default.
Did I document how the auto-protection by default is determined during installation?
Comment #9
Dries CreditAttribution: Dries commentedAgreed that we should not protect the node forms by default, assuming there is an elegant way to exclude them.
Comment #10
sunYes, it's a one-line-change. But I'm curious whether the API docs actually work. :-D
Comment #11
sunThis should do it.
Comment #12
sunComment #13
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD and DRUPAL-6--1.