Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
As far as I can tell, the webform integration doesn't work. Specifically, it looks for the string 'webform_client_form' in form_ids, which isn't the case for the D8 version of webform. I feel like there should probably be a nicer way of matching webform form ID's, but for now updating the string matching to 'webform_submission' should do the trick.
Patch to follow
Comment | File | Size | Author |
---|---|---|---|
#7 | 2870691-honeypot-webform-integration.patch | 2.05 KB | mr.baileys |
| |||
#7 | webform-honeypot.png | 93.48 KB | mr.baileys |
#2 | honeypot-webform-integration-2870691-2.patch | 703 bytes | stevetweeddale |
|
Comments
Comment #2
stevetweeddale CreditAttribution: stevetweeddale at ComputerMinds commentedComment #3
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedYeah; I never have changed things to support the new Webform 5.x (descended from YAMLform). I would like to make sure to also add some sort of test for this.
Comment #4
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedIt seems that the actual form ID is in the pattern
webform_submission_[form-machine-name]
. For example, I created a webform titled 'Test form', and when it's rendered, theform_id
iswebform_submission_test_form
Have you tested this patch manually? At a glance, it seems like more work needs to be done to make sure Honeypot applies to webforms correctly.
Comment #5
rodrigoaguileraThen maybe the strpos should be against "webform_submission_" instead of "webform_submission"
Comment #6
stevetweeddale CreditAttribution: stevetweeddale at ComputerMinds commentedAs far as I remember it works! Looking at it, I'd say the str_pos is just checking for the presence of that substring. So I guess #5 is right in that the trailing _ would still match valid webform ID's, but reduce the chance of false positives (say someone made a form with the id "something_webform_submission"). Though IIRC the old webform ID's worked the same way (eg webform_client_form_15).
Truth be told, ideally there'd be a nicer way entirely of determining if a form was a webform, besides string matching the form ID.
Comment #7
mr.baileysI think using the
webform_submission_
prefix is the correct approach to determine whether or not a form is a webform. Webform itself seems to use this check in at least one place: http://cgit.drupalcode.org/webform/tree/modules/webform_node/webform_nod... . An alternative approach might be to check for the '#webform_id' propertyHowever, Webform itself also comes with Honeypot-integration. If both Webforms and Honeypot are enabled, you can enable Honeypot support on all webforms via Webform Settings > Third Party Settings > Honeypot Integration. It does not make sense to implement integration between the two modules in both places, so I suggest removing the support for Webforms from the Honeypot module, and let Webforms handle it.
Patch attached that removes support for Webforms from Honeypot. I am not sure we need an upgrade path, since the settings has never really worked in the first place. We might want to warn a user on update that the setting is removed, directing them to the Webform Honeypot settings instead?
Comment #8
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedSounds good to me. I think a warning on update is overkill, but I might add a note on Honeypot's project page at least.
Comment #10
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commented