- I think the “don’t create entry” as the default setting on the honeypot failure was a huge mistake. Our client lost a lot of leads because people thought their messages were going through and Gravity Forms would just dismiss the entry completely and with no way to get the information;
- That this enhanced version is tied to a system that has worked well for years without issue;
- That there is no way to disable one without disabling both;
Not answering your question (I’ll leave that to the Rocketeers); but:
The JS honeypot uses a hash (unique code) that changes with each version of Gravity Forms. When you update Gravity Forms, you must clear your page cache, otherwise your forms will continue using the previous version’s hash and you will get honeypot failures. Ideally, GF would trigger that on update, but it does not.
Thanks Ross for the information. Not sure I understand “with each version of Gravity Forms” (are you saying plugin version, or form?) - but our WP Rocket cache has a 10 hour lifespan, and re-looking at the settings to see if I could exclude the Gravity Forms
gravity* I realized we’re only minimizing the JS, not combining or optimizing inline JS, so theoretically the JS optimization should have had no effect on Gravity Form’s function. So, if you are saying with plugin updates the hash changes, a 10 hour lifespan would have cleared the cache. We have also gone in and cleared the cache multiple times during testing and are still receive hash failures.
We’ve been checking on all of our sites and we are seeing this behavior on a lot of them now! This enhanced honeypot seems to be breaking forms on almost all of our websites at one point or another, different hosting systems and different caching plugins.
At this point we are having to turn off honeypot to make sure our clients are getting their leads. And clients are definitely not happy that they could have been missing a lot of leads because of this behavior.
By “with each version”, I meant every time you update the Gravity Forms plugin.