Most web forms suffer from a common issue - spam. There are plenty of approaches to minimise this, common ones including honeypot fields, and captcha (Google’s reCaptcha being the most popular).
On a recent site development, we found that Statamic’s built-in honeypot detection wasn’t sufficient and the client received an influx of spam submissions. They weren’t keen on linking to Google for reCaptcha, so we went back to a solution we’ve used to great effect on WordPress sites in the past - the ‘David Walsh technique’.
On WordPress sites we used to use the excellent ‘Zero Spam’ plugin to implement this, but there was no Statamic equivalent. Our team quickly implemented the technique on the site, making use of Statamic’s form tag customisations, some custom Javascript in the site’s JS bundle, and a custom Form event listener to validate the submitted enquiries and the spam was quickly back under control.
It was quickly apparent though that a more generic solution would be useful - after all this was something we could use on multiple sites and a less-custom approach would be beneficial for us, so our team started work on making it into a general purpose Statamic add-on.
Unfortunately, Statamic didn’t contain all of the customisation options we needed to implement the add-on in the way we wanted. Fortunately due to the open nateu of its source, we were able to submit some changes to Statamic to allow more customisation of Form tag output, as well as improvements to the way event listeners were auto-discovered.
The Statamic core team were super-responsive and the changes were merged into a public release within a couple of days, allowing us to finish packaging up the form protection as a generic add-on.
We migrated our initial site across without issues, and have now released the add-on for anyone to use:
https://statamic.com/addons/ademti-software/form-protection
With the public add-on, protecting a form is now as simple as toggling an option in the form settings.
