All add-ons currently require PHP 7.4 or greater.
On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.
Please read about the changes to BoldMinded add-on licensing.
Ticket: Snaptcha + Freeform spam protection clashing
| Status | Resolved |
| Add-on / Version | Snaptcha 3.3.1 |
| Severity | |
| EE Version | 7.3.6 |
Niki Wolf
Jun 19, 2024Description of the problem
Apparently there is a previously known issue between Freeform 3.0.5 & Snaptcha, that I only have just run into, but it’s just in one singular form out of 13. The rest work fine. It is built differently than the others are. Even with using the tag {exp:snaptcha:field security_level="1"}, it still fails to submit and gets caught in Freeform’s spam count. I even tried toggling off all of Freeform’s spam control options and it STILL is getting caught as spam.
So my request is simple – a way to disable Snaptcha on a per-form basis. Is that available? I don’t see it in the documents if it is. Could security level = 0 become an option that could be created to turn it off?
I’d prefer not to have to try to refactor the form as it is nothing like the ones that work.
Also this feature request would be helpful to some other folks who are running into this same problem where Snaptcha is getting in the way for one type of form but is wanted on other types.
How To Reproduce Steps to reproduce the behavior: 1. Create Freeform form with either the fancy tag pair options, or in my case, no freeform rendering but simple inputs with custom submit button behaviors & fancy “loading” spinner. 2. Attempt to submit form. 3. Gets caught in Freeform’s spam controls, regardless of low Snaptcha security level or toggling all of Freeform’s toggle-able spam control options to ‘off’.
Error Messages None. Silent failure. In the case of my issue with the spinner, if I disable Freeform’s “simulate successful submission” in the spam controls, it just spins indefinitely as the timeout in the JS seems to be failing to operate. Also there are no errors in the console log when this ‘mouse trap’ effect happens.
Environment Details:
- EE Version: 7.3.6
- Version: 3.3.1
- PHP Version 8.1
- MySQL Version 8.0.36
- OS: Ubuntu 20.04
- Web Server: it’s on Digital Ocean, I believe it’s running Apache as it does observe the .htaccess files.
Niki Wolf
I gave that tag a try and it seems it may work, but it also seems like I am having to force refresh any page that the form is on (which is every page in this case), before it actually works, which isn’t exactly scaleable…
Also it seems the original automatic hidden Snaptcha field is still being added, it just adds this one after the fact and seems to override it.
I did notice this before when I first was using the exp:snaptcha tag with IDs… on some forms it was only being added once, but on others the Snaptcha fields were doubled up - the original and the new one with id. That seems especially redundant/
BoldMinded (Brian)
> known issue between Freeform 3.0.5 & Snaptcha
What issue is this and who is it known by? Solspace? I haven’t heard about this.
BoldMinded (Brian)
I ask because this sounds more like an issue with Freeform than Snaptcha.
Niki Wolf
There is a thread in the EE Slack from the other day, in general I think, where someone was asking about the two addons, although it’s in the thread as it starts off asking about reCaptcha v3, so the issue between the two comes up further in the thread.
https://eecms.slack.com/archives/C04CUNNR9/p1718725008497659
BoldMinded (Brian)
If you want to disable Snaptcha just for Freeform, then you’ll need to set the enabled column to “n” in the exp_extensions table.
Providing a way to opt out of specific forms via a template tag is a more involved process. I don’t have a copy of Freeform to test with though, but if you wanted to share a zip I could take a look. Not sure what the timing would be though.
Niki Wolf
That’s much more of a hammer method than I’d like to try, given that, for me, it’s working fine on the other 12 Freeform forms and is just the one that is being a pain, so I’ll hold off on that. That may work for the other person though, I don’t know if all of their forms are Freeform or if it’s just the one and the others are different, so I can pass that along.
I’ll get you a copy of it to work with for investigation purposes.
Niki Wolf
Comment has been marked private.
BoldMinded (Brian)
Can you just post a link to the download in a private message here?
TBH if it worked before Freeform 3.0.5 and doesn’t work with Freeform 3.0.5, I wonder what changes were made. This feels like something that should be resolved in Freeform.
Niki Wolf
Comment has been marked private.
BoldMinded (Brian)
Niki, has anyone at Solspace looked into this? I looked into this a bit and I’m not sure I can, or want, to approach it from the side of “disable Snaptcha only for this one form” type option. It would require essentially adding another hidden field to the form telling it to ignore that form, but if that field is not recognized by another add-on such as Freeform, then Freeform might still prevent the submission. Since Freeform has it’s own spam prevention built in, this just feels like a scenario where you use Snaptcha or Freeform, or turn off the Freeform hooks in Snaptcha, or have Solspace take a look at it and resolve it from their side.
BoldMinded (Brian)
You also said “It is built differently than the others” - so just 1 form isn’t working, but others are, even though Snaptcha is present on all forms and all forms are Freeform? That feels a little bit like a red flag… what is different about that form than the others?
Niki Wolf
You know what, I think I figured out what the key is behind why Snaptcha is breaking Freeform for some people, along with why 12 of my forms work and a single lone one did not…
It’s this parameter:
Literally that is it.
The form of mine that is broken had it that way. The others, have it this way:
“form” vs. “form_name”. That’s it.
I changed the broken one to “form_name=” and it works.
The problem is I don’t know why this makes a difference?? They’re both in the mod.freeform_next.php file as parameter options. It does look like “form_name” was the FreeformClassic way of doing it as it’s also in the migration files.
I’ll take this up with Solspace, because if they do upgrades and decide to do away with accepting “form_name” vs. “form” as a parameter, then definitely all of our forms will end up breaking, and that will be, well, a deal breaker for us.
Thanks and sorry any lost time on this.
Niki Wolf
Correction - this is the format, the one above is wrong:
BoldMinded (Brian)
Glad you figured it out. And I do agree that does seem like a weird fix. Perhaps something inside of Freeform wasn’t updated to account for the parameter change, thus some code is running, or not running, as expected.