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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

FileSize
1.42 KB
Dries’s picture

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

Dave Reid’s picture

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.

sun’s picture

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.

Dave Reid’s picture

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.

sun’s picture

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

Dave Reid’s picture

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.

sun’s picture

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?

Dries’s picture

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

sun’s picture

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

sun’s picture

Status: Needs work » Needs review
FileSize
765 bytes

This should do it.

sun’s picture

Status: Needs review » Reviewed & tested by the community
Dries’s picture

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.

  • Commit d158386 on master, fai6, 8.x-2.x, fbajs, actions by Dries:
    - Patch #672788 by Dave Reid, sun: do not enable protection for all...

  • Commit d158386 on master, fai6, 8.x-2.x, fbajs, actions by Dries:
    - Patch #672788 by Dave Reid, sun: do not enable protection for all...