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.

Per @Input's comment in #34, attached is a patch which makes weight configurable.

This patch is for 7.x.

Moving back to 2.2.x

Certainly makes sense. Rather than bikeshed the number have it set in the config, then it can be altered when the bots learn it position.

The above MR which makes weight configurable for D10+. It also adds an entry for the tour.

How about just having a visible handle for the honeypot field in the form editor that allows to control its position (and the underlying weight) on the form? Similar to how https://www.drupal.org/project/manage_display → would allow you to manage the position of a node’s title on the ‘Manage Display’ tab of the node configuration, I can imagine this could work pretty well for the honeypot field as well. It would need some logic to ensure this is only visible on forms that have the honeypot field enabled, but that sounds doable. This would be more convenient than having to input a specific weight, especially as the weights might change when adding or removing fields on the form.

I have looked at all the patches in this issue, and only MR !44 is viable. But please review the issues in 🌱 [meta] Modifications to the Honeypot form element Active to be sure this solution doesn't conflict with those other problems.

One thing the MR lacks is a hook_update_N() to set the new configuration value for sites that are updating. New sites will automatically get all the configuration settings, including the new one, but old sites won't have that new setting and thus will have an error when trying to access or use that new setting. And to ensure that the weight isn't changed unexpectedly, should the update function should keep the value at 100 like it is now?

Like all changes to the site data (config settings in this case), this should be accompanied by an update test. It's simple enough to write. The current set of tests pass because the MR doesn't add a test to the settings form tests, and nothing in the MR affects the currently-tested code.

I think the approach in #45 is OK, but it would require manually configuring the hidden honeypot form element for each different content type. Then what about non-content-type pages? It would still require an approach like in MR !44 to add the element weight to the honeypot user interface, and to store and use that weight as the default. But I find having to set and store a different weight for each content type etc. is a problematic strategy for site maintainers. On the whole, I think I would like to get MR !44 committed first before trying to change the UI used for settings weights.

I added a hook_update_N() for the new config variable, along with a test fixture and update tests. Those test are now working.

This could still use a few community reviews.

I set the default value of element_weight to be 100, since that reproduces the current behavior on existing sites, so there is no potential to break existing sites when adding this feature. But that also means existing sites and new sites won't get any benefits by default either, unless the site adminstrator decides to alter the element_weight. Perhaps it would be better to just go ahead and set it to 1 instead, with a warning printed by the update hook that if it causes problems you should go to the settings page and change the element_weight back to 100.

FWIW, I've downloaded the new patch with the tests etc and applied it as required. It still makes the needed changes and the tests look like they are completing as expected.

I have also looked at:

#3002022: Add server-side unique-ID or unique token validations → : These should be ok to work together as expected, although the update hooks will need to be renumbered.
#2897690: Honeypot field showing up at bottom of all forms where enabled → : Whichever goes in first, the other will likely require a re-roll, but while related, they are doing different things.
#2726697: Configurable placeholder label → : This is more closely related to the above.
#3154557: Randomize the honeypot hidden field title → : The same issue, I think it is more closely related to the title.
#3134078: Conflicting name with other element(s) → : As above, this is also title-related, it will cause issues when the above issues start to progress, but it won't affect this issue.
#2944843: Accessibility Issue Triggered → : All good as this patch only moves the field up or down rather than changing any labels etc.

Also not sure why the PHPCS test is failing, it looks like it needs.
`use Drupal\rules\Core\RulesEventManager;`
to be moved after:
`use Drupal\Tests\rules\Unit\Integration\Event\EventTestBase as RulesEventTestBase;`
which looks like PHPCS is treating the capital `Tests` as alphabetically ahead of `rukes`

Thanks for looking it over. What do you think - should we go with a weight of 100 or 1?

Don't get me started on the alphabetizing.
The use statements in Honeypot were put in alphabetical order last year in 📌 Sort 'use' statements alphabetically. Fixed .

But about a week ago Drupal changed the definition of "alphabetical order", with no change record or notice or documentation to inform us about what the new rules are - the only notice was the tests suddenly started reporting errors where there were no errors before.

Now I'm getting these phpcs failures in all my projects and I have to re-do the "alphabetical" ordering in hundreds of .php files. What a waste of time. Reminds me of the @file fiasco of a couple of years ago where first we had to add @file comments to every .php file (over 1000 in my projects) then this policy was later reversed and @file comments we were forbidden, so they all had to be removed.

I'm happy with leaving it as 100 in the default, that that is what it is currently.
That being said, I will be changing all my configs to 1 as it works to keep the field above the submit button in my experience.

My opinion is that we should set the weight to 1 by default, not just for new module installations but also for existing sites.

Part of the goal with this issue is to fix the problem where the honeypot field is being ignored by semi-intelligent bots. The most likely culprit is that a weight of 100 typically means it is rendered after the submit button(s), and so bots ignore it. If we leave the default weight at 100, this module continues to be useless against semi-intelligent bots.

I imagine many site admins don't read through every changelog for every module update, and so they will miss a message that says: "New feature: you can set the weight of the field which is currently 100. It's recommended to set this to a weight of 1." So unless they make the change (either via manual config, or updating the variable in deploy scripts), the module will continue to be useless against semi-intelligent bots.

OK, changing the default to 1 and updating the MR.