Better results if honeypot-field is placed as first field

Played arround a little bit with the weight. 100 as default, which puts the hidden field behind submit actions, makes Honeypot nearly useless. -1 has for some reason a similar effect. Getting it between name and mail-Field with 2 reduced Spam to 0 (for the moment) and effectively triggering the "trap".

In my opinion this value should be configurable by the user via UI to find out which position fits best and give some flexibility over time to the user and less predictability for bots.

Also (but this is an other issue) the field label should be configurable. Last has at least some effect. I run multilingual sites and I changed the non-english label via translation, which reduced spam at least a little bit. But this may be just a subjektive point of view, so giving the user config-options adds flexibility and the comfort of best fit.

I still don't know how to make or work with patches yet (some day). But I did alter the code in the module's HoneypotService.php file to this:

		// Build the honeypot element.
    if (in_array('honeypot', $options)) {
      // Get the element name (default is generic 'url').
      $honeypot_element = $this->config->get('element_name');
			$alt_titles = [
				'website_address',
				'fav_number',
				'apartment_number',
				'maiden_name',
				'favorite_cereal'
			];
			if($honeypot_element == 'url'){
				$random_number = rand(0, 4);
				$honeypot_element = $alt_titles[$random_number];
			}
			$replace_underlines = str_replace('_', ' ', $honeypot_element);
			$label_title = ucwords(strtolower($replace_underlines));
      // Build the honeypot element.
      $honeypot_class = $honeypot_element . '-textfield';
      $form[$honeypot_element] = [
        '#theme_wrappers' => [
          0 => 'form_element',
          'container' => [
            '#id' => NULL,
            '#attributes' => [
              'class' => [$honeypot_class],
              'style' => ['display: none !important;'],
            ],
          ],
        ],
        '#type' => 'textfield',
        '#title' => $this->t($label_title),
        '#size' => 20,
        '#weight' => 0,
        '#attributes' => ['autocomplete' => 'off'],
        '#element_validate' => [
          [$this, 'validateHoneypot'],
        ],
      ];

    }

Based on some of the ideas in some of these related issues, I've added an array of element name options to be selected randomly if you leave the default 'url' option in the config page. It then replaces the underscore for a blank space to create the #title, redefining the element label and the element machine name at the same time. Lastly, I set the #weight option to 0.

Now the field appears first in the forms and randomly changes the field label and input ID and classes based on the 5 options I've provided.

The resulting HTML look slike this:

<div class="maiden_name-textfield" style="display: none !important;"><div class="js-form-item form-item js-form-type-textfield form-item-maiden-name js-form-item-maiden-name"><label for="edit-maiden-name">Maiden Name</label><input autocomplete="off" data-drupal-selector="edit-maiden-name" type="text" id="edit-maiden-name" name="maiden_name" value="" size="20" maxlength="128" class="form-text"></div></div>

I will continue to monitor the results. I just started using this module today and prior to making these changes, I was only seeing "time-base" results in the logs and still getting spam submissions. I will be trying additional methods but I will give this a few more days. Over the weekend we got hit with a non-stop attack that I was only able to stop by changing the access level of each of my webforms. Within minutes I had over 700 spam submissions come into my email. I just turned the forms back on this morning.

If anyone would like to turn this into a patch for me, I will love you forever.
:)

Drupal 9.5.11
Webform 6.2.2
Honeypot 2.1.3

As of today, spam is still coming through but Honeypot is registering more blocking in the log reports due to "honeypot field" usage rather than just "time" blocking. Before these edits to the module, I was not seeing "field" logs.

@tenten71 Here is your patch, I added a description to the field as I think the text "Leave this field blank." should be attached somehow, otherwise if anyone does happen to see the field, they won't know to leave it blank.
Uploaded without prejudice, as I am not sure this should be changing the Title as it is.
Personally, I think this issue should be dealing with the weight, and perhaps #2726697: Configurable placeholder label → should be dealing with the title configuration.

The last submitted patch, 37: honeypot-field_weight-2811189-37.diff, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

That patch I just uploaded fails as the tests expect a field called url, which the patch changes to be url-{{random_number}}.

If that is the chosen solution, the test can be updated to proper look for something more appropriate.

My own personal vote is for the patch at #27, which sets the weight to 1 rather than the later patches which set the weight to -1.
I think the Title can be set in another issue.