3.0 doesn't work config never passed to handler

Created on 21 February 2025, about 2 months ago

Problem/Motivation

The module doesn't work because the code that retrieves the settings was removed from the validateForm method in the handler.

Previously, the settings were retrieved as follows:

    // Get values from Webform spam words settings.
    $wsw_settings = \Drupal::config('webform_spam_words.settings');
    $spam_words = $wsw_settings->get('spam_words', 'SEO');
    $spam_words_error = $wsw_settings->get('spam_text_message', 'Unable to submit form. Please contact the site administrator, if the problem persists.');
    $spam_field = $wsw_settings->get('spam_field_name', 'message');

In the 3.0.x branch, the code calls $this->configuration, which always returns the values set in the defaultConfiguration method. This happens because the setConfiguration method was never implemented. As a result, the handler does not use the configuration set in the configuration form.

Steps to reproduce

  1. Install the module version 3.0.0
  2. Enable webform UI
  3. Go to contact webform in the settings tab go to Emails / Handlers and add Webform Spam Words
  4. Go to contact form fill inputs and set message to "SEO" and submit it will work

Proposed resolution

Since the handler doesn't retrieve or use the configuration from the config form, the configuration should be moved to the handler level rather than implementing a setConfiguration method.

The first option is better, in my opinion, because in some use cases, we need to avoid spam words on specific webforms but not others. For example, I need to block "SEO" on the contact webform but allow it on the business webform. With the current implementation, this is not possible.

Remaining tasks

User interface changes

The configuration from /admin/config/webform/webform-spam-words to handler form.

API changes

Data model changes

๐Ÿ› Bug report
Status

Active

Version

3.0

Component

Code

Created by

๐Ÿ‡ซ๐Ÿ‡ทFrance berramou

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @berramou
  • Merge request !13Resolve #3508387 "3.0 doesnt work" โ†’ (Closed) created by berramou
  • Pipeline finished with Failed
    about 2 months ago
    Total: 147s
    #431056
  • ๐Ÿ‡ซ๐Ÿ‡ท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 ?

  • Pipeline finished with Success
    about 2 months ago
    Total: 147s
    #431060
  • Pipeline finished with Success
    about 2 months ago
    Total: 160s
    #431391
  • First commit to issue fork.
  • Pipeline finished with Failed
    24 days ago
    Total: 146s
    #451301
  • Pipeline finished with Failed
    24 days ago
    Total: 146s
    #451302
  • ๐Ÿ‡บ๐Ÿ‡ธ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,.

  • Pipeline finished with Failed
    22 days ago
    Total: 250s
    #453613
  • Pipeline finished with Success
    21 days ago
    Total: 158s
    #454486
Production build 0.71.5 2024