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

Přehled změn

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 any plugin to stop a submission — and Kadence have said they are retiring it.
• New [Integrations]: MC4WP (Mailchimp for WordPress) newsletter signup forms are now supported. Junk signups do more damage than junk email: they fill your mailing list with addresses that bounce, and that in turn harms the delivery of every newsletter you send afterwards.
• New [Integrations]: The „lost password“ form is now protected, both WordPress’s own and WooCommerce’s. Left open, that form can be used to send password emails to any address a spammer cares to type in — the people receiving them have never heard of your site, and the resulting complaints damage the reputation of your domain, which then costs you every other email you try to send. Nothing about this shows up as spam on your own site, which is why it usually goes unnoticed.
• New [Integrations]: The WooCommerce „account details“ form is now protected. Note that it is only ever shown to logged-in customers, and the plugin skips logged-in visitors by default, so this only takes effect if you have turned that off.
• Improvement [Support]: The support link inside the plugin now leads to the SilentShield support board for this plugin instead of a general page.

2.12.1

• New [Elementor]: Elementor’s new v4 forms — the „atomic“ forms, built on the new element system — are now protected. They were not before, and not because the protection failed on them: these forms assemble what they send entirely in the browser and only include the fields Elementor itself placed, so everything this plugin adds was dropped on the way out and the form arrived looking like an ordinary, unprotected submission. Its fields now travel with the request. Nothing of ours appears in your notification email or in the submissions table, and the classic Elementor form widget is unaffected.
• Fix [Captcha]: On sites with page caching the reload button stopped working, and did so silently. The button sent a security token that WordPress stamps into the page itself and only accepts for about a day; a cached page keeps serving that token long after it has expired, and WordPress then turned every click away before the plugin ever saw it. The button no longer sends that token. It does not need one — the address the request comes from is checked instead, which a cache cannot invalidate. This affects the same on every form plugin, not only Contact Form 7.
• Fix [Captcha]: If your site sends visitors‘ browsers the instruction not to disclose which page they came from — a common privacy setting, and one some privacy extensions apply on their own — the reload button, the audio button and the timing refresh were refused outright. They were relying on exactly the information that setting withholds. They now use signals the browser sends regardless, so the setting no longer costs you a working captcha.
• Fix [Captcha]: The limit on how often a new captcha could be requested was counted per address as your server reports it. Behind a CDN or load balancer that is one and the same address for everybody, so all your visitors together shared a single allowance of thirty requests a minute — busy enough sites simply ran out, and the reload button then stopped working for everyone at once. The limit now counts each visitor separately, using the proxy setting you may already have configured.
• Fix [Captcha]: A reload that failed used to leave no trace whatsoever: the old captcha stayed on screen, nothing was said, and nothing was written to the browser console unless you knew about an undocumented debug switch. There was no way to tell a refused request from a broken connection, and nothing useful a visitor could report. A failed reload now says so next to the captcha and records the reason in the browser console.
• Fix [Admin]: The SilentShield navigation column could disappear entirely, leaving no way to reach any of its screens — the sidebar was still on the page, but hidden, and the button meant to bring it back did nothing. The plugin’s own styling was competing on equal footing with a rule WordPress itself ships, and which of the two won came down to the order the stylesheets happened to load in. A theme, another plugin, or anything that combines stylesheets could tip it. The sidebar no longer depends on winning that race.

2.12.0

• Fix [Admin]: On sites whose permalinks are set to „Plain“, several screens inside the plugin were simply empty — the Audit Log, the Mail Log and the Analytics figures showed nothing at all, no matter how much had actually been recorded. The records were never lost; the plugin was asking WordPress for them with a malformed address and getting nothing back. All of those screens fill in again after this update. Sites using any other permalink setting were never affected.
• New [Setup]: A newly installed plugin protects nothing until you switch on the form plugins you use, and until now nothing said so — it sat in your plugin list marked „active“ while every form on the site was still wide open. There is now a notice in the WordPress admin, and a panel on the SilentShield dashboard, naming the form plugins found on your site and linking straight to the screen where you turn them on. Nothing is enabled for you: switching on something like the WordPress login form uninvited is how people end up locked out of their own site. Both disappear as soon as anything is protected.
• New [Logging]: When the SilentShield API is in use, its answer to each check is now written to the Audit Log — verdict, confidence and the server’s actual reply — so a decision can be examined afterwards instead of being taken on trust. Failed calls are always recorded, including what came back; recording the successful ones as well is a new switch under Advanced → Logging & Tracking, off by default because it writes one entry per submission. Submissions turned away for carrying no behaviour token are logged now too: that is the most common reason a form is blocked, and it previously left no trace at all.

2.11.0

• New [Protection]: The hidden fields the plugin adds to your forms — the honeypot and the two JavaScript timing fields — no longer carry the same names on every site. They are now named per page load, derived from a signed token, so a spam script can no longer be built once against the fixed names and pointed at every site running this plugin.
• Fix [JavaScript protection]: The page age a submission claimed was taken from a hidden field that anyone could set to any value, which meant a form could be fetched once and re-submitted for as long as the spammer liked. That age now comes from a token signed with your site’s own secret and is rejected once it is older than 24 hours. Submissions that carry no token at all — form HTML held in a page cache, or rendered before this update — keep being accepted as before, so nothing breaks when you update.
• Fix [JavaScript protection]: A submission whose end time was before its start time counted as valid, because the difference was rounded to whole milliseconds and only compared against zero. Such submissions are now rejected, as are those where both timestamps were written in the same instant.
• Fix [Honeypot]: A bot that wrote „0“ into every field it found passed the trap, because a zero counted as „left empty“. It no longer does.
• Fix [Honeypot]: The trap field was marked visibility:hidden in its style attribute — a reliable signal for a scraper looking for the one field it must not touch. It is now moved off-screen instead, and is properly kept out of the tab order and away from screen readers and browser autofill.
• Fix [Blacklist]: The words you typed into „Blacklist Words“ never blocked anything. The rule reads its list from WordPress’s own Comment Blocklist, and the current settings screen was saving your words somewhere else — the switch reported itself as on, the list looked saved, and nothing was ever caught. Saving now writes through to that list, and the field is filled back in from it, so what you see is what is actually in use. If you had the blacklist switched on, it starts working after this update — which is what the setting promised all along.
• Fix [Elementor]: On Elementor pages the captcha could freeze. Elementor stores a page’s rendered markup for 24 hours, and everything the plugin adds to a form was being stored with it — the same arithmetic question and the same captcha session for every visitor from then on, which is no captcha at all. Worse, whatever your settings were at that moment was frozen in too, so turning a protection on afterwards changed nothing until the cache expired. The form is now excluded from that cache; everything else on the page still benefits from it.
• Fix [Captcha]: „5 – 4 = ?“ has the answer 0, and a zero was being …