GravityForms Honeypot sending all to spam?

Get Help
, , , , ,
1

Hello. It seems after a recent Gravity Forms plugin update, that the honeypot is failing on our site, sending ALL entries directly to spam. We did not have it set to save spam entries in a spam folder. Turned that option on, did a test, PayPal pops up, try to submit the payment, a generic “message received” occurs. PayPal doesn’t complete, form doesn’t get submitted, user doesn’t get notice from PayPal or website since it was marked spam, it stops processing.

Our solution was simply to disable the honeypot option on Gravity Forms for now and we’re able to process forms and donations again. But I wanted to try and bring this to someone’s attention in case it helps, and also so the development team can look into the issue.

I am saving logs, here’s a snippet:

2024-11-25 9:44:18.251147 - DEBUG → Gravity_Api::check_license(): getting site and license info
2024-11-25 9:45:16.195761 - DEBUG → GFFormsModel::create_lead(): Draft entry created for form (#5) in 0.007658 seconds.
2024-11-25 9:45:24.608367 - DEBUG → GFFormDisplay::process_form(): Starting to process form (#5) submission.
2024-11-25 9:45:24.610639 - DEBUG → GFFormDisplay::process_form(): Source page number: 1. Target page number: 0.
2024-11-25 9:45:24.610713 - DEBUG → GFFormDisplay::validate(): Starting for form #5.
2024-11-25 9:45:24.610735 - DEBUG → GFFormDisplay::validate(): Checking restrictions.
2024-11-25 9:45:24.610966 - DEBUG → GFFormDisplay::validate(): Completed restrictions. Starting field validation.
2024-11-25 9:45:24.611196 - DEBUG → GFFormDisplay::validate_character_encoding(): Starting invalid characters validation for field: Name (3 - name)
2024-11-25 9:45:24.611677 - DEBUG → GFFormDisplay::validate_character_encoding(): gf_entry_meta meta_value charset = utf8mb4
2024-11-25 9:45:24.611731 - DEBUG → GFFormDisplay::validate_character_encoding(): reflecting methods
2024-11-25 9:45:24.611778 - DEBUG → GFFormDisplay::validate_character_encoding(): Completed in 0.000581 seconds. Value is valid ascii
2024-11-25 9:45:24.611852 - DEBUG → GFFormDisplay::validate_character_encoding(): Starting invalid characters validation for field: Billable Company Name (if applicable) (6 - text)
2024-11-25 9:45:24.611871 - DEBUG → GFFormDisplay::validate_character_encoding(): Completed in 0.000020 seconds. Value is valid ascii
2024-11-25 9:45:24.611948 - DEBUG → GFFormDisplay::validate_character_encoding(): Starting invalid characters validation for field: Address (23 - address)
2024-11-25 9:45:24.611968 - DEBUG → GFFormDisplay::validate_character_encoding(): Completed in 0.000021 seconds. Value is valid ascii
2024-11-25 9:45:24.612330 - DEBUG → GFFormDisplay::validate_character_encoding(): Starting invalid characters validation for field: Please enter the name of the campaign or organization your donation is on behalf of (38 - text)
2024-11-25 9:45:24.612360 - DEBUG → GFFormDisplay::validate_character_encoding(): Completed in 0.000031 seconds. Value is valid ascii
2024-11-25 9:45:24.612467 - DEBUG → GFFormDisplay::validate_character_encoding(): Starting invalid characters validation for field: Please enter the name of the person this gift is in honor or memory of: (32 - text)
2024-11-25 9:45:24.612488 - DEBUG → GFFormDisplay::validate_character_encoding(): Completed in 0.000022 seconds. Value is valid ascii
2024-11-25 9:45:24.612612 - DEBUG → GFFormDisplay::validate_character_encoding(): Starting invalid characters validation for field: Additional Comments / Requests (28 - textarea)
2024-11-25 9:45:24.612632 - DEBUG → GFFormDisplay::validate_character_encoding(): Completed in 0.000022 seconds. Value is valid ascii
2024-11-25 9:45:24.613962 - DEBUG → GFFormDisplay::validate(): Field validation completed in 0.002949 seconds.
2024-11-25 9:45:24.614002 - DEBUG → GFFormDisplay::validate(): Executing functions hooked to gform_validation.
2024-11-25 9:45:24.616697 - DEBUG → GFFormsModel::create_lead(): Draft entry created for form (#5) in 0.002615 seconds.
2024-11-25 9:45:24.617949 - DEBUG → GFCommon::is_spam_entry(): Executing functions hooked to gform_entry_is_spam.
2024-11-25 9:45:24.618349 - DEBUG → Gravity_Forms\Gravity_Forms\Honeypot\GF_Honeypot_Handler::validate_honeypot(): Is honeypot input empty? true
2024-11-25 9:45:24.618406 - DEBUG → Gravity_Forms\Gravity_Forms\Honeypot\GF_Honeypot_Handler::validate_honeypot(): Is version_hash input valid? false
2024-11-25 9:45:24.618422 - DEBUG → Gravity_Forms\Gravity_Forms\Honeypot\GF_Honeypot_Handler::validate_honeypot(): Are both inputs valid? false
2024-11-25 9:45:24.618464 - DEBUG → GFCommon::is_spam_entry(): Result from gform_entry_is_spam filter: true
2024-11-25 9:45:24.618485 - DEBUG → GFCommon::is_spam_entry(): Spam checks completed in 0.000601 seconds. Is submission considered spam? Yes.
2024-11-25 9:45:24.618673 - DEBUG → GFFormDisplay::validate(): Completed gform_validation.
2024-11-25 9:45:24.618705 - DEBUG → GFFormDisplay::process_form(): After validation. Is submission valid? Yes.
2024-11-25 9:45:24.618746 - DEBUG → Gravity_Forms\Gravity_Forms\Honeypot\GF_Honeypot_Handler::handle_abort_submission(): Result from Honeypot: true
2024-11-25 9:45:24.618762 - DEBUG → GFFormDisplay::process_form(): Aborting early via gform_abort_submission_with_confirmation filter.
2024-11-25 9:45:24.618792 - DEBUG → GFFormDisplay::handle_confirmation(): Preparing confirmation (#67448d8497118 - Default Confirmation).
2024-11-25 9:45:24.618838 - DEBUG → GFFormDisplay::handle_confirmation(): Executing functions hooked to gform_confirmation.
2024-11-25 9:45:24.618864 - DEBUG → GFFormDisplay::handle_confirmation(): Completed gform_confirmation.
2024-11-25 9:45:24.618977 - DEBUG → GFFormDisplay::handle_confirmation(): Confirmation to be used =>

Thanks for contacting us! We will get in touch with you shortly.

2024-11-25 9:45:24.619007 - DEBUG → GFFormDisplay::process_form(): Processing completed in 0.010862 seconds.
2024-11-25 9:45:25.307660 - DEBUG → GFFormDisplay::get_form(): Preparing form (#5) confirmation completed in 0.008235 seconds.

Steve - Web Dev for Nancy Chavez

1 Like
2

See the following:

3

We are having the same problem. Lost thousands of leads over the weekend because of that. 2.9 update caused it (some of the sites didn’t auto update to 2.9.0 and all worked on 2.8.18. All the sites on 2.9.0 with honeypot enabled did not register any submissions.) We tried to clear the cache, disabling the cache (siteground pagespeed), but that didn’t help. Only disabling honeypot helped.

4

If the issue remains once the caches are cleared and the page is excluded from caching and optimization, the next step is to run through a complete conflict test using the steps outlined on this documentation page: Testing for a Theme/Plugin Conflict

5

This seems to be an error with GravityForms core. The JavaScript for this changed between version 2.8.3 and 2.9.0. If I set a breakpoint at the line where the version hash field gets inserted, the breakpoint never hits. The submission version hash is empty and the entry is automatically marked as spam.

6

I’ve got it. In my case, we were modifying the onclick attribute on the submit button. I’m guessing before 2.9.0, a default submit button looked like this: onclick="gform.submission.handleButtonClick(this);". In this release, it seems to have changed to onclick="gform.submission.handleButtonClick(this)".

Since we appended to the onclick attribute, it changed to onclick="gform.submission.handleButtonClick(this) someOtherFunction();". The lack of the semicolon in between the functinos broke the first one, and so the version hash code never fired.

7

The semicolon is back in the latest hotfix version available from your support account. That said, when using the gform_submit_button filter to modify the onclick attribute I do recommend checking that the attributes current value ends with a semicolon before appending your custom script, like the example here: gform_submit_button - Gravity Forms Documentation

8

Thank you Chris, I had a feeling it wasn’t necessarily a cache issue, and I’m hesitant to test that theory and turn honeypot back on because we are in the middle of a donation campaign and people weren’t able to contribute until I disabled honeypot.

Fortunately, we have other spam prevention in place.

The other issue I’m having with the cache thing is because this wasn’t ever an issue before until the 2.9 update came through. I really appreciate your input on this topic and situation.

9

Same here, probably triggered since a very recent upgrade.
Verified timing here:

  • all worked fine up to Nov 21
  • today all submissions are marked as spam (we can’t verify in-between submissions)

Gravity_Forms\Gravity_Forms\Honeypot\GF_Honeypot_Handler::validate_honeypot(): Is version_hash input valid? false
=> there is no version_hash in the POST payload

It works when I deactivate hCaptcha for WP – WordPress plugin | WordPress.org, though that plugin hasn’t changed since Nov 21, I therefore suspect a change happened within a recent GF update.

Checked:
1/ caching is exactly the same with/without the hcaptcha plugin
2/ no js errors to be found
3/ no php errors or warnings to be found
4/ ALL submissions are being marked as spam when the honeypot is active

We could disable the honeypots, but since this is a setting the editors can re-enable by accident, we don’t want to bet on them staying deactivated.

10

Actually, the main concern going forward is the feedback message when the honeypot detects a false positive. In the docs:

The form confirmation will display the default “Thanks for contacting us! We will get in touch with you shortly.” message instead of the forms configured confirmation.
https://docs.gravityforms.com/spam-honeypot-enhancements/#h-new-setting

=> This was the main concern today: we missed submissions AND our clients have been falsely reassured all is OK (!) and they just have to wait.

Could this by default be changed with non-positive feedback please? Or could there be an extra setting on the honeypot field for this copy?

11

You can use the gform_confirmation filter to display a custom confirmation, or your configured confirmation, when the form fails honeypot validation or the entry is marked as spam:

1 Like
12

2.9 replaces the jQuery-based form submission handler with a new version that uses plain JavaScript, which also includes new hooks and events that developers can use to trigger their integrations. The developer of the hCaptcha plugin will most likely need to update their integration so it uses the new submission handler instead of the old one.

1 Like
13

If anyone else is having trouble after installing the latest hotfix release from Log In ‹ Gravity Forms — WordPress and clearing your cache and CDN, please open a support ticket:

https://www.gravityforms.com/open-support-ticket/technical/

I’ll close this topic. Anyone is free to open a new topic as necessary. Thank you.