SilentShield – Captcha & Anti-Spam for WordPress (CF7, WPForms, Elementor, WooCommerce)

SilentShield is a unified captcha and anti-spam plugin for WordPress.
It works with the most popular form builders and protects login, registration, and comment forms – without slowing your site.

Why choose SilentShield?
– Invisible defense – Captcha, honeypot, and blacklists working silently.
– Instant results – Install, activate, and stop spam.
– Universal support – Works with Contact Form 7, WPForms, Elementor, Formidable, Ninja Forms, Forminator, Kadence, WooCommerce, and more.
– Privacy-first – No cookies, no tracking, fully GDPR / DSGVO compliant.

SilentShield doesn’t just protect forms.
It protects your time, your customers, your business.

Core Features

• Invisible Captcha (Arithmetic, Honeypot, Image)
• Smart IP Blocking & Blacklists
• Spam filters for links, code & keywords
• Whitelisting for admins & customers
• GDPR-ready, no cookies, no tracking

Supported Form Plugins & Integrations

SilentShield protects forms from all major WordPress form builders and core features:

Form Builders:
– Contact Form 7 (CF7)
– WPForms / WPForms Lite
– Elementor Pro Forms (classic widget and v4 “atomic” forms)
– Gravity Forms
– Fluent Forms
– Formidable Forms
– Ninja Forms
– Forminator
– JetFormBuilder
– Kadence Blocks (Advanced Form)
– Jetpack Forms (contact form block and shortcode)
– Avada (Fusion Builder) Forms

Newsletter:
– MC4WP – Mailchimp for WordPress (signup forms)

WooCommerce:
– Checkout – block (the default for new shops since WooCommerce 8.3)
– Checkout – classic (incl. PayPal Payments)
– Login
– Registration
– Lost password
– Account details

WordPress Core:
– Login form (wp-login.php)
– Registration form
– Lost password form
– Comment forms (including WooCommerce product reviews)

Communities & Forums:
– bbPress (new topics and replies)
– BuddyPress (member registration)

Donations:
– GiveWP (classic donation form; the visual-builder form is not yet covered)

Other:
– Ultimate Member (Login & Registration)
– WP Job Manager (Job Applications)

Each integration can be enabled or disabled individually under Settings > Extended.

Protection Layers

SilentShield uses 10+ protection mechanisms working together:

1. Captcha – Arithmetic math, honeypot, or image-based captcha
2. JavaScript Protection – Detects submissions from bots without JS support
3. Browser Detection – Validates User-Agent strings
4. Timer Protection – Blocks submissions faster than a human can type
5. Multiple Submission Protection – Prevents rapid duplicate submissions
6. IP Rate Limiting – Limits requests per IP and time window
7. IP Blacklist – Block known bad IPs
8. Content Rules – Limit URLs, block BBCode, keyword blacklist
9. Gibberish Detection – Recognises submissions filled with random characters, the kind a bot writes when it only needs the form to go through. Unlike every other check it does not depend on the sender’s browser, so a bot driving a real browser cannot pass it by playing along. Starts in observation mode and blocks nothing until you switch it on.
10. Whitelist – Skip validation for admins, logged-in users, or specific emails/IPs
11. SilentShield API – Cloud-based spam detection (silentshield.io)

The Promise

SilentShield is not “just another plugin.”
It’s an invisible wall against the background noise of the internet.

Activate once – and your forms are human again.

Want more? SilentShield API

Everything above is free and stays free. No feature is held back, no submission limit, no account needed.

What the free plugin cannot do is recognise a bot that behaves like a person — one driving a real browser, solving the captcha, typing at human speed. Rules can only catch what looks wrong, and those do not.

The SilentShield API answers that with behaviour analysis and browser fingerprinting, scored in the cloud, and it usually decides without showing anyone a captcha at all. Switch it on and the local protections stay exactly where they are as a fallback — if the API is ever unreachable, your forms are still protected.

There is a free plan and a trial, and you can see what it would have caught before you pay for anything: turn on Comparison Mode and the plugin logs what the API would have decided, alongside what your local rules actually did.

👉 Plans and free trial at silentshield.io

Privacy & Telemetry

• No cookies, no user tracking.
• Encrypted IP storage (max. 2 months, only for spam defense).
• Every transmission described below is optional and can be switched off in the plugin settings.
• The plugin’s built-in Privacy page shows which of these are active on your site, what that means, and gives you ready-made privacy-policy snippets in 25 languages.

1. Plugin statistics (setting “Telemetry”)
Anonymous, no personal data, sent at most once a day:
– plugin_slug, plugin_version
– snapshot_date
– settings_json (anonymized config – only boolean/integer flags, no free-text)
– features_json (enabled features)
– created_at, first_seen, last_seen
– counters_json (spam events)
– wp_version, php_version, locale

2. AI-crawler observation (setting “Observe AI crawlers”, on by default; SILENTSHIELD_OBSERVER to force off)
Sent only for requests identified as an AI crawler — never for your human visitors. Delivered after the page has already been sent to the visitor:
– ua (the crawler’s User-Agent), ip, path (without query string), method
– The IP address is pseudonymised on the server (daily keyed hash) and never stored in the clear.

3. Blocked-request reports (only with “Block AI crawlers (enforce)” on; follows the observation setting above)
Same fields as (2), plus the outcome (deny / throttle), for every request enforcement turned away. Note that a block rule which is not restricted to a specific crawler can also catch a human visitor — that request is then reported in the same way.

4. Form assessment (only with the SilentShield API enabled)
See the API snippet on the plugin’s Privacy page for the full description.

1. Upload to /wp-content/plugins/.
2. Activate via WordPress “Plugins” menu.
3. Configure protection settings under Settings > SilentShield.

For detailed setup instructions, see docs/installation.md.

1. 

   IP Protection settings

2. 

   Spam protection in comments

3. 

   Contact Form 7 integration

4. 

   Avada Forms integration

5. 

   Image Captcha example

6. 

   Arithmetic Captcha example

7. 

   Honeypot Captcha example

8. 
9. 
10. 
11. 
12. 

2.15.8

• Fix [SilentShield API]: The page shown next to a blocked submission is now the page your site actually served, not one the sender claimed. That address was taken from the browser’s referrer header, which whoever sends the request is free to set to anything at all, or to leave out entirely. A bot doing either cost you the one detail that says where to go and look: the block still counted, but it arrived carrying somebody else’s domain — which has to be discarded — or carrying nothing. The plugin works the page out on the server that served it now. Where a form is sent in the background, as Contact Form 7, the comment form, Elementor and others do, the page is resolved from the post the form sits on, so a blocked comment names the article it was posted under rather than whichever address happened to arrive. Nothing about how submissions are checked has changed, and sites without an API key send nothing either way.
• Fix [Ultimate Member]: Blocked sign-ins and blocked registrations are counted separately now. Both forms were reported under a single name, so your statistics could not say whether you were looking at attempts to guess passwords for existing accounts or at attempts to create fake ones — two rather different problems, needing rather different answers. Each form is now named in its own right.
• Fix [Ultimate Member]: A refused sign-in was counted three times. Ultimate Member checks the entered credentials itself, and doing so set this plugin’s WordPress-login protection going a second and a third time on the very same submission. One refused sign-in therefore produced three entries in your statistics and three rows in the block log, and spent three captcha challenges on its own. It is judged once now, and counted once. Sites not using Ultimate Member were never affected.

2.15.7

• Improvement [SilentShield API]: Your dashboard now counts every submission this plugin turns away, not just one kind of it. Until now only a single case was reported — a submission that arrived without the behaviour token, typically a bot running no JavaScript. Everything else the plugin refuses on your site (a failed captcha, a filled honeypot, a form sent faster than anyone could read it, a duplicate submission, gibberish content, a blocked address, your own content rules) was handled correctly but never mentioned to SilentShield, so none of it appeared in your statistics. All of it is reported now, each with its own reason, so the dashboard shows what is actually being stopped rather than a fraction of it. Sites not using the SilentShield API are unaffected — nothing is sent from them, and nothing about how submissions are checked has changed on any site.
• Improvement [SilentShield API]: Reports now name the form that was hit, so a dashboard can show which of your forms is under attack instead of only that something was. Forms whose integration cannot name them are still reported, just without the name.
• Improvement [SilentShield API]: The plugin version now travels with the regular key check, so SilentShield can tell you in your dashboard when a site is running an outdated version. Previously the version was only ever sent with the anonymous daily usage statistics — which carry no key and therefore could not be matched to your account, and which stop entirely when you switch that reporting off. Nothing new is sent from sites without an API key, and no new connection is made: the version rides along on a request the plugin was already making.

2.15.6

• Fix [API]: The cause behind 2.15.4’s refused submissions is now closed off for good. That release repaired the five integrations where the SilentShield API rejected every genuine visitor as a bot, but it repaired them one by one — the route that let them go wrong was still open, and any integration added later could have taken it just as easily. The field the API checks for is now produced by the part of the plugin that checks it, so no form can be drawn without it. If you use the API, nothing changes for you: forms that worked keep working. What changes is that this class of failure can no longer reappear on an integration nobody has looked at yet.
• Fix [API]: With the API switched off — which is how it ships — every form still carried a hidden field and a small script belonging to it, for a library that was never loaded on those sites. They did nothing and were sent to every visitor on every page with a form. They are now only added when the API is actually in use.
• Fix [API]: On a site protected by the API alone, with no other protection switched on, forms carried no SilentShield markup at all. The plugin looked as though it were not installed while the server refused everything the page sent, which is the hardest version of this to diagnose from the outside. Such forms are now marked up correctly.

2.15.5

• Fix [IP protection]: On any site whose timezone is not UTC, IP protection refused legitimate submissions. After one successful submission, every further submission from the same IP address was refused for the length of the site’s offset from UTC — two hours on a German site in summer time — no matter what “period between submits” was set to, and setting it to zero did not help either. The submission was lost silently: no email, no entry in the form plugin’s own submission table, only a blocked line in SilentShield’s mail log. What made this expensive is that an IP address is not a person. One visitor submits successfully, and the next person behind the same connection — a second member of a household, a colleague in the same practice, anyone sharing a provider’s address — is turned away for the next two hours; so is the same visitor noticing a forgotten detail and sending again. The cause was that the time of a submission was written in the site’s timezone but read back as UTC, which placed it in the future and made the waiting period impossible to satisfy. Times are now written and read the same way throughout. West of Greenwich the error ran the other way and IP protection did not limit anything at all, so sites in the Americas regain a protection that was quietly inactive. Only sites with IP protection switched on were affected — it is off by default. Nothing needs to be configured; the update clears the plugin’s IP log, which holds nothing but this rate-limiting state and is emptied automatically every three weeks anyway. Existing blocks are kept.
• Fix [IP protection]: The counter behind “max retries” ignored its time window and counted every attempt still on record rather than only those inside the configured period, which made a block possible on attempts that were hours or days apart. It now honours the window.
• Improvement [IP protection]: A submission is now let through, and the reason written to the log, whenever the check cannot reach a sound verdict — a stored time that lies in the future or cannot be read, a missing internal key, or a database error. Previously the last of these ended the submission with a server error instead: the visitor saw an error page and the enquiry was gone. A protection that cannot decide must not be the reason a genuine enquiry is lost. This is the rule the gibberish detection has followed since 2.15.2.

2.15.4

• Fix [Elementor, JetFormBuilder, Avada, Gravity Forms, Ultimate Member]: With the SilentShield API switched on, every genuine submission on these five was refused as a bot. The API decides using a token the plugin puts into the form, and on these five integrations that field was never added — so nothing arrived, and a submission with no token is refused by design. The visitor filled in the form correctly, pressed Send, and was told it looked automated. Where the API was the only protection in use, the effect was worse still: the plugin then placed nothing at all in the form, so the page looked as though no protection were installed while the server refused everything that came from it. The field is now added on all five, the same way it always was on the other twenty-one integrations. If you use one of these five together with the API, this restores your forms; nothing needs to be configured. Sites not using the API were never affected, and neither were Contact Form 7, WPForms, WooCommerce or any of the other integrations.
• Fix [JetFormBuilder]: Settings made for a single JetFormBuilder form applied only when a submission was checked, not when the form was drawn. A protection switched on for one particular form was therefore expected by the check but never placed in the form — and every submission of that form was refused, with no way to tell from the page why. Both halves now read the same settings. Only forms with their own settings under Forms were affected; sites using the same settings everywhere were not.

2.15.3

• Fix [Privacy]: The plugin’s own settings screens loaded a font from Google’s servers. Opening any SilentShield page in the WordPress admin fetched the “Inter” typeface from fonts.googleapis.com, and a request to Google’s servers carries the IP address of whoever made it. On a plugin whose purpose is data protection this should never have been the case, and under the GDPR it is the kind of transfer that needs a legal basis nobody had established. The font now ships inside the plugin and is loaded from your own server; not a single request leaves your site any more. Only administrators opening SilentShield’s settings were affected — never visitors, and never anyone filling in one of your forms, because the file was only ever loaded inside the admin area. Nothing changes in how the settings look, and nothing needs to be configured. The font has been part of the plugin since version 2.10.0, so any site running that version or later was affected; if your data protection documentation lists the services your site contacts, this entry can be removed from it.

2.15.2

• Fix [Protection]: On some hosts, every form submission failed with a server error. The gibberish detection used PHP’s mbstring extension, which is optional and which WordPress itself does not require — it supplies replacements for the two functions it needs and no more. Where the extension was missing, the check ran until it reached a function nobody had replaced and stopped the request dead. The visitor pressed Send and got an error page; no email arrived, and nothing in the plugin’s own logs said why. It made no difference that the detection ships in monitoring mode and was not entitled to reject anything: it never got as far as a verdict. The check no longer uses the extension at all. Separately, the gibberish detection can now no longer end a submission by failing, whatever the reason — if it cannot finish, the submission is let through and the reason is written to the log. Only hosts without mbstring were affected; sites where forms have been working are unaffected.
• Improvement [Protection]: While rewriting the above, six characters turned out to have been counted as consonants: the Turkish ı and İ, the Nordic ø, and long vowels such as ā and ū. Names written with them looked slightly less pronounceable to the detection than they are — a small bias against Turkish, Baltic and Scandinavian names, in the one direction that costs a real enquiry rather than a spam. They now count as the vowels they are.
• Fix [Forminator, Ninja Forms]: When a submission was refused, the explanation was attached to the form’s first field so it would appear next to it — but “first” was taken literally, and a form that begins with a hidden field (a tracking value, a pre-filled ID) had the message attached to something nobody can see. The visitor pressed Send, no email arrived, and nothing at all appeared on screen. Hidden fields are now skipped. This is the same silent failure fixed for Avada in 2.15.0, arrived at by a different route; it was found by checking whether that bug could exist elsewhere, and these two are where it could.
• Fix [Elementor]: The same check on a form built entirely from hidden fields left nowhere to put the message, and it was dropped. It is now shown above the form instead.

2.15.1

• Fix [Translations]: French sites were not seeing the plugin’s own translations at all. When WordPress.org publishes a community translation for a plugin, WordPress uses it instead of the one the plugin ships — not in addition to it. Anything the community translation happens not to cover then falls back to English, even where the plugin has a complete translation for that language sitting right there. French has had a community translation since 7 August, so French sites had quietly been showing English wherever it had a gap. Both are now used together: the community translation still comes first, and the plugin’s own fills whatever is left. Nothing changes for languages without a community translation. This affects Persian in the same way, and would have hit any other language the moment one appeared.
• Fix [Translations]: The list of integrations under Forms was in English no matter what language your site is in — “WordPress Comments”, “WooCommerce Checkout”, “Password Reset (WordPress & WooCommerce)” and the other twenty-four. The names had never been marked as translatable, so no translation of them existed in any language, and there was nothing a translator could have done about it. They are translated now in all twenty-five languages the plugin ships. Product names stay as they are: bbPress is still bbPress, only the part in brackets is translated.
• Improvement [Admin]: The settings screen for the SilentShield API was still called “Beta” in the menu, which read as a warning about the feature rather than a label. It is now “API / SilentShield”, the same name the newer admin interface has used for a while. Only the name changed — the page, its address and your settings are untouched.
• Fix [Translations]: The plugin’s own menu was in English too — Dashboard, Analytics, Audit Log, Beta, Extended and Forms. Help and Upgrade were translated, which is what made it look like a partial translation rather than a missing one.
• Fix [Translations]: On the default captcha template, the line under the puzzle (“Please enter the characters shown in the CAPTCHA…”) and the reload button’s label were always English — for your visitors, on every site, in every language. They had been written in a way that made them invisible to the translation files, so no language ever had them. This is the only one of these fixes your visitors will notice rather than you.
• Fix [Translations]: Eight messages on the dashboard, the ones confirming that logs, timers, captchas or IP bans have been cleared, were spelled with a text domain the plugin does not use. They could not be translated in any language and never had been. Fixed and translated.
• Fix [Translations]: Around ninety further texts had never reached the translation files at all: the audit log, the setup notice, the AI-crawler settings and their data-protection notes, the weekly report, the feedback question shown on deactivation, and the descriptions under most of the protection settings. If you have ever wondered why a settings page was half in your language and half in English, this is why. All of them are translated now.
• Fix [Translations]: One admin notice was in German for everyone, in every language, including on German sites where it only looked correct by accident — the one that appears when the SilentShield API cannot be reached and the local protection modules take over. It is now written in English and translated like everything else.
• Fix [Translations]: “%d Overrides” and “%d forms found” on the Forms screen could not be translated because of a gap in the tooling that reads the source code: it never looked for texts that change with a number. Both are translated now, in each language’s own plural forms — three of them in Polish and Czech, four in Slovenian and Maltese.

2.15.0

• New [Integrations]: Jetpack Forms is now supported — both the contact form block and the older [contact-form] shortcode, which are the same form underneath. Jetpack is installed on several million sites, and where one of them has a contact page, this is usually the form on it. You have to switch this on, as with every integration: it appears under Forms as “Jetpack Forms”.
• New [Integrations]: bbPress is now supported, for new topics and for replies. Forums that allow guests to post are among the most reliably spammed things on a WordPress site, because every post is public, permanent and carries links — and unlike a contact form, nobody has to read the spam for it to do damage.
• New [Integrations]: BuddyPress member registration is now supported. An open community signup collects fake profiles rather than emails: they stay on your site, they are indexed, and clearing them out later means going through your member list by hand.
• New [Integrations]: GiveWP donation forms are now supported. Donation forms are not spammed the way a contact form is — they are used for card testing, where somebody runs stolen card numbers through a small donation to find out which ones still work. You do not notice it in an inbox; you notice it in chargebacks and in a payment processor asking questions. This is worth switching on even on a site nobody would bother sending spam to.
• Fix [Protection]: A refused submission could tell the visitor that the captcha was not correct without saying which check had refused it — the message stopped at the colon and nothing followed it. The protection itself worked correctly throughout; only its name was missing, and only on some forms, which is why it went unnoticed for so long. It was most likely to appear exactly where it costs the most: on a donation or payment form, where somebody who simply mistyped is left with a refusal and nothing to correct. Every rejection now names the check that made it.
• Fix [Protection]: On a form that has no captcha field, every submission after the first was turned away as a duplicate. The duplicate-submission check hands the form a one-time token and discards it the moment it is used, so the browser has to be given a fresh one after each submission — and it only ever was as a side effect of the captcha being redrawn. Where there was no captcha to redraw, nothing replaced the token, and the form kept sending the used one. On forms that submit without reloading the page, which is most of them now, the effect was immediate: the first enquiry arrived, the second was refused, and the mail log recorded it as a duplicate submission although the visitor had written something entirely different. Refreshing the page cleared it, so it looked intermittent. The token is now renewed independently of whether a captcha is present.
• Fix [Protection]: The same token is also renewed on pages served from a full-page cache, and after a browser back/forward restore. A cached page hands every visitor the same token, so the first person to submit used it up and everyone after them was refused — on a cached site with this check enabled, that meant one successful submission per cache refresh. Both cases now fetch a fresh token when the page opens. This also restores the intended behaviour of the minimum-time check on cached pages, where the countdown previously began when the cache was written rather than when the visitor arrived.
• Fix [Avada]: A submission Avada refused could fail completely silently — the visitor pressed Send, nothing appeared, and no email was sent. The refusal message is attached to one of the form’s fields for Avada to display next to it, and the field chosen was worked out by discarding everything recognisable as hidden. On a site running a second anti-spam plugin, the field that survived was that plugin’s honeypot, which is positioned off-screen by design, so the message was placed somewhere no one could see it. The form’s own field list is now used to make that choice, which cannot pick a field the form does not visibly contain; where no visible field exists, the message is shown above the form instead of being lost.

• Improvement [Logging]: “Duplicate submission” in the mail log stood for three unrelated things — a genuinely reused token, a token this site never issued, and a form sent back faster than the configured minimum. The commonest of the three was the stale token described above, which is not a duplicate at all, so the log confirmed a diagnosis that was wrong. Each is now recorded under its own reason, with a line saying what actually happened and what to look at. Nothing changes about which submissions are blocked.

• Note [GiveWP]: This covers the classic donation form, not the newer one built in GiveWP’s visual form builder, which has been the default for new forms since GiveWP 3.0. Both still ship, and which one you have depends on when the form was made. If your form was built in the visual builder, it is not protected by this — please check rather than assume, because we would rather tell you plainly than let you believe a form is covered when it is not. The newer form assembles what it sends in the browser and only includes fields it knows about, so the timing checks that catch automated donations cannot travel with it. We are working on it.

• Note [bbPress]: Whether a rejected post shows a reason depends on your theme. bbPress hands error messages to the theme to display, and not every theme does — the one we tested against shows nothing, for bbPress’s own errors just as much as for the captcha’s. If a post is refused and nothing appears to happen, that is what you are seeing; the post is not created either way.
• Note [Jetpack]: A submission that fails the captcha is turned away with a message the sender can read, rather than being quietly filed as spam. Jetpack offers both, and the quiet option is the wrong one here: the person who mistyped a captcha is usually a customer, and filing their enquiry away while showing them a success message means they believe they have written to you and you never find out that they did.

2.14.1

• Fix [Protection]: On English-language sites, a blocked submission named its reason with an internal identifier rather than words — “Captcha not correct: captcha-protection”, or “rule-protection: blacklist” where one of your own filter rules had matched. The person reading that has usually just mistyped a captcha, and to them it looks like the website is broken rather than like an explanation. Every other language the plugin ships already had proper wording; English was the one that did not. The nine messages now read as plain labels: “Captcha check”, “IP check”, “Timing check”, “Duplicate submission”, “Filter rule: …” and so on. Nothing changes about which submissions are blocked — only about what the visitor is told. It became more noticeable in 2.14.0, because the message for a rate-limited address is now shown for the whole duration of the block instead of only on the submission that triggered it.

2.14.0

• New [WooCommerce]: The block checkout is now protected. This is the checkout WooCommerce gives every new shop since version 8.3, and until now it received no protection at all — not a weakened version, none. Captcha, honeypot, timing checks and blacklists were all switched on and doing their work everywhere else on the site, while an order placed at the checkout itself went through untouched. Nothing indicated this: the plugin listed WooCommerce as protected, because it was — the older, classic checkout was. The two are separate pieces of software that happen to sell the same basket, and the block checkout offers none of the places the classic one does for a plugin to step in. You have to switch this on. It appears as its own entry, “WooCommerce Block Checkout”, under Forms, next to the existing “WooCommerce Checkout” — turning that one on does not cover it, and never did. If you are unsure which checkout your shop uses: open your checkout page in the editor, and if it shows a single “Checkout” block rather than a shortcode, it is the block one.
• Improvement [WooCommerce]: If your checkout block sits on a page other than the one WooCommerce has been told is your checkout — a landing page, a one-page shop, a custom funnel — the plugin previously loaded nothing there at all, so no protection could run even where it was configured. It now recognises the checkout block wherever it is placed.
• Fix [Protection]: When the rate limit blocked an address, only the submission that triggered the block said so. Every attempt for the rest of the block — an hour by default — was turned away with whatever generic wording your form plugin uses when it is given no reason, so a site owner testing their own form a few times in a row locked themselves out and then had a form that refused everything and explained nothing. One person spent hours switching protections off one at a time to find out which one it was. The block now names itself for its whole duration, exactly as the first rejection always did.
• Fix [Logging]: The anonymous measurements the new content check records were being written to the same place as the log of blocked submissions. Those two are governed by separate switches with opposite defaults — measuring is on, the block log is off until you ask for it — so on a normal installation that table filled up with measurements and contained not a single actual block. Anyone opening it while looking for the reason a submission was turned away found only rows belonging to submissions that had been let through, and at least one person reasonably concluded the content check had rejected their enquiry when it had done the opposite. Measurements now have their own place. Existing rows are moved across on update; nothing is lost, and the figures shown on the Analytics screen were correct throughout and do not change.
• Improvement [Protection]: The new content check judged a field holding a single long word by that word alone, which is a poor basis for a decision when the field is a name, a town, or a German sentence whose only long word is something like “Rechnungsanschrift”. A lone word now has to look far more clearly machine-generated before it counts against the field; where a second long word is present, nothing changes. Real spam is unaffected — it fills whole fields with generated text, and every one of those was rechecked against this. The explanation written alongside each measurement also says plainly what happened to the submission and what it counted, instead of “1 of 1 words”, which meant “one of the one words long enough to judge” and was read, understandably, as a word count.

2.13.0

• Fix [Avada]: Notification emails from Avada forms arrived with the plugin’s own hidden fields listed underneath the enquiry — rows like “F12 Timer” followed by a long string of characters. Nothing was broken and no data was at risk, but to the person reading the email it looked like a malfunctioning website, which is a poor thanks for protection that was otherwise doing its job. Avada is the only form plugin that emails back everything a form sent rather than a message you wrote yourself, which is why it happened there and nowhere else. Those fields are now removed before Avada builds the email, and they no longer appear in the stored submission or in Avada’s own entries list either. Two of them had also been kept in the plugin’s mail log all along, where nobody happened to look; that is fixed by the same change.
• New [Protection]: A new check reads what was actually typed into your forms and recognises the kind of spam that fills every field with random characters — a name like “Cowqv Exnjznedy”, a town like “JPnuTSVqMlNmdwoFObq”. This catches something the other checks cannot: they all work by giving the visitor’s browser something to return, which a spam program driving a real browser simply hands back correctly. Judging the text instead does not care how good the program is at pretending to be a person, because writing nonsense is the whole point of what it is doing. It starts in observation mode and blocks nothing until you switch it on under Protection, so it cannot turn a real enquiry away while you are still deciding. It never looks at more than one field in isolation: a single unusual name or product code is normal, and only a submission where several fields are nonsense counts. Non-Latin alphabets are skipped entirely rather than guessed at.
• New [Integrations]: Formidable Forms is now supported. It was the one major form plugin that every comparable captcha plugin protected and this one did not.
• New [Integrations]: Ninja Forms and Forminator are now supported.
• New [Integrations]: Kadence Blocks is now supported, for its Advanced Form block. Kadence’s older classic form block cannot be protected — it offers no way for …