- Issue created by @berramou
- ๐ซ๐ทFrance berramou
Thank you for your contribution,
i'm sorry it seems my MR has more than the bug fix and my issue not a bug, maybe we can change this issue to feature request ? - First commit to issue fork.
- Merge request !14Issue #3508387: Load and use the module's configuration โ (Open) created by briantschu
- ๐บ๐ธUnited States briantschu West Orange, NJ
I opened a new merge request, which loads the module configuration, rather than changing tack to make the spam words configurable per each form within the handler.
Attaching a patch for ease of deploying this update until a fix is released.
- ๐ซ๐ทFrance berramou
Hello @briantschu,
Thank you for your contribution! It's good to do a quick fix release. However, in my opinion, the configuration should be at the webform level. As I mentioned in the description, in some cases, users may need to block spam words on certain webforms but not on others.
For example, in my case, I have two webforms: one for contact inquiries, where I want to block SEO-related words, and another for service information requests, where I donโt want to block SEO words, as they could be relevant to my clientโs inquiry.
Apologies for the mix-up in the issueโit is a bug, but it also fixes something else.
Maybe we could create a related issue to add this as a feature?
- ๐ซ๐ทFrance berramou
And another thing the check used
if (strpos($value, mb_strtolower(trim($word))) !== FALSE)
blocks words even if they are just part of another word. For example, if "SEO" is in my configuration, the word "Seoul" also gets blocked, which is not good. - ๐บ๐ธUnited States briantschu West Orange, NJ
Being able to customize the configuration on a per-webform basis does sound like a nice feature! However, I think that should be a separate issue since moving to that style of configuration is not a requirement to get the module working as it did previously. There's another, slightly related, issue requesting there to be the ability to configure spam words per field on a webform โ , as well. Perhaps those efforts could be combined.
I think the issue with partial word matching returning false positives should be another separate issue. I'd be happy to take a look at that one with you.
On a larger scale, it seems like this module could benefit from some automated tests. I've never written tests personally, but I'd be curious to try since we're using this on a large number of sites at my organization.
- ๐ซ๐ทFrance berramou
Yes, you are right. The two fixes, "Moving configuration to webform level" and "partial word matching," are out of the scope of this issue.
I will create an issue for the partial word matching returning false positives and will move the development I did here to that issue:
Configure spam words per field on a webform โ .As for the tests, I would love to help out with them. If you can add me as a maintainer,.