backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

[UX] Have contact.module enabled by default on the standard profile. #1571

Open klonos opened 8 years ago

klonos commented 8 years ago

This is part of #1168

To me it simply does not make sense to have this module disabled since most sites have a contact form and this module is required in order to enable one.

quicksketch commented 8 years ago

To me it simply does not make sense to have this module disabled since most sites have a contact form and this module is required in order to enable one.

Though as a point of caution, a contact form is a prime target for bot-spam. I'm not sure having contact module turned on in every demo/testing site out would make for happy users who may suddenly start getting spammed by their own site.

klonos commented 8 years ago

Yeah, this is the same issue like having the setting for creating new user accounts to "Visitors, but administrator approval is required" as the out-of-the-box default I guess. How about we implement #1169 for both forms then?

mikemccaffrey commented 8 years ago

To me it simply does not make sense to have this module disabled since most sites have a contact form and this module is required in order to enable one.

Yes, most sites have a contact form, but many of them are starting to be implemented by third-party services. For the project I was just working on, they wanted to embed a Salesforce form so that anyone contacting them got turned into lead. Other organizations may want to questions being fed into a ticketing system, instead of just being sent via email.

Though as a point of caution, a contact form is a prime target for bot-spam.

I agree that this is a big risk factor, and I don't think adding honeypot alone is sufficient to ensure that someone's website doesn't suddenly start sending out spam messages without them explicitly looking to enable the contact functionality.

klonos commented 8 years ago

Other organizations may want to questions being fed into a ticketing system, instead of just being sent via email.

I think that this calls for a swappable/pluggable API or something so that form output is in a very basic/generic/raw format that can then be fed into plugins that actually do something with it. Something like Mail System in core I guess (if I got this right). The default (with core) could be email, but could easily be altered to do whatever people want with forms.

mikemccaffrey commented 8 years ago

I think that this calls for a swappable/pluggable API or something

Hmm... that would certainly be the direction taken if we were Drupal developers. However, let's try to keep things as simple as possible for as long as possible.

I'd be interested in keeping the Contact module disabled by default, and then see the analytics (once we get those sorted out) of how many sites actually end up enabling that functionality. If it truly ends up being the majority of sites, we can then move to enabling it by default.

jenlampton commented 6 years ago

I actually agree with the contact module being enabled by default, but I'd prefer to see something like honeypot in core before (or at the same time) if we go that route.

stpaultim commented 4 years ago

Just to be clear, enabling the contact module by default alone is not enough for a SPAM threat, since upon enabling the module the default permissions seem to be set such that only admins have access to use the contact module.

If enabling the module made it more visible to admins, I would say that it's safe enough to enable it as long as the permissions are set appropriately. However, it's not clear to me that simply enabling it is really that useful, if it's not made more visible in some way.