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

Белешка о изменама

2.15.12

• Fix [Protection]: Jetpack and WPForms: with gibberish detection set to block, genuine messages are no longer turned away. Both form plugins send an encoded status value along with every form — Jetpack a long security token, WPForms a block of usage data. Gibberish detection read these values as text and scored them as dozens of random words, which on its own was enough to reject the submission. For Jetpack forms this was the case since gibberish detection was introduced in version 2.13.0; for WPForms it started with 2.15.11, when the detection began reading the fields WPForms nests inside its form. Only sites that had switched gibberish detection from observing to blocking were affected — in the default observation mode nothing was ever rejected. Values like these are now recognised and ignored, whatever a form plugin calls them, while what your visitors type is checked as before.
• Fix [Protection]: In the WordPress comment form, gibberish detection checks the commenter’s name again. Version 2.15.11 had stopped reading it.
• Improvement [Compatibility]: Tested with Germanized for WooCommerce 4.1 — classic and block checkout with its order button and terms checkbox, the EU withdrawal form, and account login and registration. Every order placed in these tests is also checked in WooCommerce itself: accepted orders are stored exactly once, refused ones not at all.

2.15.11

• Fix [Protection]: Gibberish detection now works in Elementor, WPForms and Formidable forms — until now it could never block anything there. These form plugins send their fields as a nested group (Elementor as form_fields[…], WPForms as wpforms[fields][…], Formidable as item_meta[…]), and the detection only read the top level of a submission. It therefore scored the form’s own housekeeping, such as the page title, and never saw a single word a visitor had typed: a message made of nothing but random strings went through even with the detection set to block. The same applied to Elementor’s new atomic forms and to the name field of Fluent Forms. All of them are read completely now. If you switched gibberish detection to blocking because of spam in one of these forms, it takes effect with this update.
• Fix [Protection]: Gravity Forms: gibberish detection no longer counts one of the form’s hidden fields against every submission. Gravity Forms sends an encoded status field with each form, and the detection read it as text and scored it as random characters — one „suspicious“ field in every submission before a visitor had typed anything. With the lowest threshold of two fields, one unusual real entry, such as a foreign company name, was enough to turn a genuine enquiry away. The field is ignored now.
• New [Forms]: The Forms screen now shows whether the plugin can read your forms. Next to each integration a badge says whether the fields your visitors fill in are recognised, and selecting the integration shows the details: a self-test with a sample submission in that form plugin’s format, the names of the fields found in your last real submission (never their content), and whether gibberish detection blocks or only observes there. If your last test submission came from a whitelisted visitor — usually you, testing while logged in as an administrator — it says so, because such submissions are never checked.
• Improvement [Compatibility]: Tested with WordPress 7.1 and PHP 8.5. On PHP 8.5, every image captcha shown to a visitor wrote a deprecation notice to the PHP error log; on sites that log notices, that could fill the log quickly. It no longer does, and neither does the one notice the plugin caused on PHP 8.4 and later. Nothing changes for visitors, and the plugin still runs on PHP 7.4.

2.15.10

• Fix [Captcha]: After a typo, the corrected answer now goes through — in Elementor, Jetpack, Ninja Forms, Forminator and Kadence forms. Each captcha can be answered once: the attempt uses it up, whether the answer was right or wrong. These five form plugins send the form in the background and leave the page as it is, and the captcha on screen was not replaced after the answer came back. So a visitor who mistyped the code, fixed it and pressed send again was turned away a second time, with the correct answer, and could only get through by clicking the reload icon or by reloading the page and losing everything they had typed. The same happened to a second message sent from a page that stays after a success. A fresh captcha now appears as soon as the form has its answer, whatever that answer was. Forms that reload the page after sending were never affected.
• Fix [Captcha]: The captcha no longer stops reloading for visitors who share an address. Loading a new captcha is limited to 30 times per minute per IP address, to keep bots from farming them. That limit was meant to start over every minute but only did so after a full minute without a single request. Everyone behind one office or mobile network address — or a single visitor moving quickly between pages with forms — could therefore use it up for good and see „Could not load a new captcha“ until the address fell silent for a minute. It starts over every minute now, as intended.
• Fix [Privacy]: The privacy-policy text on the Privacy page now describes the SilentShield API correctly. It said, in all languages, that data is processed exclusively on servers in Germany by Hetzner, never transferred to third countries, and kept for at most 14 days. The servers are STRATO’s; Cloudflare (USA) can sit in front of the standard endpoint api.silentshield.io, while the EU endpoint api-eu.silentshield.io reaches the servers without a US provider in between — the text now covers both, with the legal basis for a transfer; and data is kept for the retention period of your plan (7 to 90 days; individually agreed plans may differ), IP addresses only as a hash. If you copied the earlier text into your privacy policy, please replace it. The plugin description no longer calls itself „fully GDPR compliant“ or says it stores „only anonymized data“: IP addresses are stored encrypted, which makes them pseudonymised, not anonymous.

2.15.9

• Improvement [Captcha]: The hint above the image captcha can now be changed. Templates 1 and 6 show „Enter the characters shown in the image:“ above the image instead of the captcha label, and that text was fixed — the label setting had no effect on it, and the only way to change it was a translation override. It is now a setting of its own, „Image Captcha Hint“, next to label and placeholder, and it can also be set per integration or per form. Leave it empty and the built-in, translated text stays exactly as it was, so nothing changes on your site until you fill it in.

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.

Earlier versions

The full changelog, back to the first release, is in changelog.txt in the plugin folder and online.