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.



new1.42 KB

I think the current behavior is OK, so I'm not 100% convinced we need this patch. Happy to discuss it though.

1. 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.

I 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.

If 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.

Sure, 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. ;)

Status:Needs review» Closed (won't fix)

Both sides don't have any data to back it up, but sounds like this is a won't fix.

Status:Closed (won't fix)» Needs work

errr, actually I would agree with not protecting node forms by default.

Did I document how the auto-protection by default is determined during installation?

Agreed that we should not protect the node forms by default, assuming there is an elegant way to exclude them.

Yes, it's a one-line-change. But I'm curious whether the API docs actually work. :-D

Status:Needs work» Needs review
new765 bytes

This should do it.

Status:Needs review» Reviewed & tested by the community

Status:Reviewed & tested by the community» Fixed

Committed to CVS HEAD and DRUPAL-6--1.

Status:Fixed» Closed (fixed)

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