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

Nhật ký thay đổi

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 stored as “no answer at all”. Roughly one arithmetic captcha in sixty was therefore unsolvable: a visitor typed the correct 0 and was turned away as a spammer.
• Fix [JavaScript protection]: With this protection switched on, several integrations rejected every real visitor. WP Job Manager applications, the Ultimate Member login and the WordPress registration form never recorded the timing the check needs, so a genuine person looked exactly like a bot with no browser. All of them work now. If you tried this setting before and turned it back off because forms stopped working, it is worth another look.
• Fix [Maintenance]: The cleanup buttons under Database Maintenance reported the wrong number of removed entries — “0 deleted” after clearing all logs, and exactly “1 deleted” after clearing the IP log or the IP bans, however many there had been. The deleting itself was always correct; only the count was wrong, in the confirmation and in the audit trail.
• Fix [Logging]: The Status taxonomy the log entries use was registered for a post type this plugin does not have, left over from older code. It worked, but it also stayed attached to that stray name — so if another plugin ever registered a post type called “deals”, a Status column from us would have appeared in its list.
• New [Support]: There is now a way to reach us from inside the plugin. A “Feedback & Support” entry in the menu, a section at the end of the Help page, and a second button on the review notice for when something is not working — until now that notice only offered a public review, which is a poor place to report a problem. Deactivating the plugin also asks once why; answering is optional and opens our form, nothing is sent from your site.

2.10.0

• Fix [Comments]: With comment protection enabled, the captcha was applied to every comment WordPress creates — not just the ones a visitor types into the comment form. A comment added by an importer, by the WordPress app or block editor, by WP-CLI, by a scheduled task or by another plugin carries no captcha field, was therefore treated as spam, and the request was answered with “403 Forbidden” — which could take down whatever feature that other plugin was in the middle of. The captcha now applies only to real comment-form submissions. Nothing changes for the comment form itself: spam is still blocked exactly as before.
• Fix [AI-Agent Enforcement]: Two kinds of rule you can set in your SilentShield dashboard were saved and displayed as active, but the plugin never applied them. Rules by purpose were only matched against a crawler’s older category label, so blocking “AI agents” had no effect at all — the agent-type crawlers (ChatGPT-User, Claude-User, Perplexity-User, Meta, Mistral and others) are filed under a different label. And rules against faked identities were skipped entirely. Both now work. If you already had either rule switched on, those requests will start being blocked after this update — which is what the setting promised all along. Nothing else changes: rules that were working keep working exactly as before.
• Fix [AI-Agent Enforcement]: A crawler is only treated as a forgery when we can actually see where the request came from, its operator publishes IP ranges for the same address type (IPv4/IPv6), and the request comes from outside all of them. A crawler we cannot check stays “unverified” and is never accused — so a genuine bot is not blocked because we happen to hold only part of its address list.
• Fix [AI-Agent Enforcement]: Sites behind Cloudflare, an nginx front-end or any other reverse proxy are no longer at risk of turning away real crawlers. Your server sees the proxy’s address there, not the crawler’s, which would make every well-behaved bot look like a forgery. The plugin now recognises that situation and withholds the “forged” verdict; if you have set F12_TRUSTED_PROXY_HEADER in wp-config.php, it uses that header to find the real address instead — which also makes “verified” work behind a proxy for the first time.
• New [AI-Agent Enforcement]: The plugin now reports to your dashboard which kinds of rule this version can carry out. If you save a rule that needs a newer plugin, the dashboard says so instead of showing it as active.
• New [AI-Agent Enforcement]: Blocked requests are reported to your dashboard, so the “blocked bots” report has data. The report is sent after the visitor’s response has already been delivered, so it costs no page speed, and it follows the “Observe AI crawlers” setting: switch that off and blocking keeps working while the reporting stops. Transmitted are user agent, IP address, path and method of the blocked request; the IP is pseudonymised on the server.

2.9.0

• New [AI-Agent Enforcement]: The plugin can now actually enforce the block rules you set in your SilentShield dashboard — previously it could only observe. When enabled, disallowed AI bots receive a 403 (throttled ones a 429) based on the signed policy your dashboard publishes. The policy is fetched and its Ed25519 signature verified server-side (libsodium), cached, and refreshed off the request path, so pages are not slowed down. Bots are identified by their User-Agent and only treated as “verified” when their source IP is in the operator’s published range. Toggle under Advanced → “Block AI crawlers (enforce)” (OFF by default — a deliberate choice; define SILENTSHIELD_ENFORCER as false in wp-config.php to force it off). Fail-open by design: any error, an unverifiable policy, or “observe” mode never blocks a request.

2.8.0

• New [AI-Agent Observation]: The plugin can now record which AI agents/crawlers (GPTBot, ClaudeBot, PerplexityBot and others) visit your site and show them in your SilentShield dashboard. It runs entirely server-side, sets no cookies, blocks nothing, and only sends data for detected bots — never for your human visitors. IP addresses are pseudonymised server-side. The telemetry is sent after the page has already been delivered to the visitor, so page speed is unaffected. Toggle under Advanced → “Observe AI crawlers” (on by default; define SILENTSHIELD_OBSERVER as false in wp-config.php to force it off). Legal basis: legitimate interest (Art. 6(1)(f) GDPR).
• New [AI-Agent Observation]: The list of known AI crawlers refreshes itself once a day from the SilentShield bot directory (off the request path, with an embedded fallback list), so new crawlers are recognised without a plugin update.
• New [AI-Agent Observation]: A one-time, dismissible admin notice announces the feature and links to the setting — no silent telemetry.

2.7.7

• Fix [Translations]: Resolved the _load_textdomain_just_in_time notice (WordPress 6.7+) for the captcha-for-contact-form-7 domain. Four protection validators (behavior/API, captcha, multiple-submission and timer) translated their failure message inside their constructor, which runs on after_setup_theme — before init — and therefore triggered translation loading too early. The message is now resolved on the init hook via the new set_message_on_init() helper, while keeping the literal __() strings visible to the translation extractor.

2.7.6

• Security [Audio Captcha]: The accessibility audio endpoint (/captcha/audio) no longer returns the captcha solution for math challenges. The math answer was never used by the frontend (math formulas are read aloud directly from the page), so this code path only disclosed the solution to direct API callers. Image captchas still spell out their characters — that is the intended purpose of the audio accessibility feature and remains protected by the existing per-IP rate limit.
• Security [SilentShield]: Documented that the frontend beta_captcha_api_key is a publishable, domain-bound client key (comparable to a reCAPTCHA site key), intentionally exposed to the browser so the behavioral client script can run. It carries no administrative or sensitive authority.

2.7.5

• Fix [Forms]: Enabling WordPress Comments, JetFormBuilder or Ultimate Member protection no longer attaches the captcha submit interceptor to unrelated forms — most notably the WooCommerce “Add to cart” form (form.cart), which could be blocked or delayed. These three integrations relied on the generic default-forms handler, which bound to every form on the page that wasn’t explicitly excluded (an exclusion list that could never be complete). Each integration now has its own dedicated module that targets only its own forms (comment form, JetFormBuilder forms, Ultimate Member login/registration), and the generic handler is no longer activated as a side effect.

2.7.4

• New [Analytics]: When the SilentShield API is active, the Analytics page now shows an “API Exclusive Blocks” section with measured numbers — how many spam submissions the API blocked that none of the local rules (Captcha, Timer, IP, Honeypot, …) would have stopped, plus the overlap and total API blocks. Both the recording and the section are only active while the API is enabled and reachable. This complements Shadow Mode, which shows an estimate while the API is off.
• New [Analytics]: Bots that submit a protected form without ever loading the widget (no behavior nonce — typically scripts that POST directly without running JavaScript) are now reported to the SilentShield API so they are counted in the “bots blocked” statistics instead of being silently dropped. The submission is still blocked locally exactly as before; the report is fire-and-forget and never delays the request.
• Maintenance: Removed temporary debug logging from the SilentShield API validator (no longer writes diagnostic lines, including nonce/API-key prefixes, to the PHP error log).

2.7.3

• Fix [WooCommerce Checkout]: The JavaScript protection could wrongly reject legitimate checkouts (“JavaScript protection not correct”) and require several clicks on “Place order”. The captcha and its timing fields (js_start_time/js_end_time) are rendered inside the order review block, which WooCommerce re-renders on every updated_checkout AJAX (address, shipping or payment changes). The page-load init only ran once, so after a refresh js_start_time was empty and the timestamp fallback collapsed start and end to the same value (zero duration). The checkout now re-seeds js_start_time on every updated_checkout and falls back to the stable page-load time, so the submitted duration is always valid.
• Fix [Compatibility]: Resolved a conflict with Germanized for WooCommerce where enabling “WooCommerce Login” or “WooCommerce Registration” protection broke the order withdrawal/Widerruf form (?wc-ajax=eu_owb_woocommerce_order_withdrawal_request), which failed with an HTTP 500 error and no success/error message. The frontend submit interceptor was bound to the generic form.woocommerce-form class and therefore also hijacked third-party WooCommerce forms that ship their own AJAX handling. It now only targets the WooCommerce login (woocommerce-form-login) and registration (woocommerce-form-register) forms it actually protects.

2.7.2

• Fix [Forms]: Comments and other default WordPress forms now set the JavaScript timing field (js_end_time) at the moment of submission instead of on page load. Previously the timestamp was pre-filled during init, making it identical to js_start_time and rendering the time-based bot detection ineffective for these forms.
• Fix [Forms]: Default forms (comments, JetForm, Ultimate Member, generic forms) no longer ran the captcha workflow on page load. The workflow is now correctly triggered by a native submit listener, so the captcha is verified only when the user actually submits.
• Fix [Forms]: Resolved an issue where default forms with a submit control named submit (e.g. the WordPress comment form’s “Post Comment” button) could not be submitted, because the control shadowed the form’s submit() method. The form is now submitted natively via the prototype method, which also avoids re-entrant submit events.
• Fix [IP Protection]: IP rate limiting no longer wrongly blocks legitimate visitors from the third submission onward. The time check compared the gap between the two previous submissions instead of the time since the last one, so the current request’s actual timing was ignored — once a visitor’s first two submissions were close together, every following submission (e.g. the third comment on a post) was rejected with “IP protection” regardless of how long they waited. The check now correctly measures the time elapsed since the visitor’s last submission.

2.7.1

• Improved [Translations]: French (fr_FR) translations overhauled — replaced anglicisms with correct French terminology throughout (“spam” → “indésirables”, “bots” → “robots”, “plan” → “offre”, “plugin” → “extension”, “clé API” → “clé d’API”, “paramètres” → “réglages”, “analyse comportementale IA” → “analyse comportementale par IA”, “espace réservé” → “texte indicatif”, “étiquette” → “libellé”). Fixed typos and grammar errors in community-contributed translations. Regenerated MO and JSON files.

2.7.0

• Fix [Admin UI]: Resolved sidebar/navigation not rendering on sites with WooCommerce or other React-based plugins. The plugin now uses WordPress’ built-in React instead of bundling its own copy, preventing duplicate React instance conflicts that broke context providers.
• Fix [Cron]: “Daily Telemetry” cron job no longer runs when telemetry is disabled. Previously, disabling telemetry in the admin UI only took effect on the next page load; the cron could still fire in between. Cron state is now synced immediately when settings are saved.
• Fix [Cron]: Audit log no longer shows “Daily Telemetry completed” entries when telemetry is disabled. The audit hook for the telemetry cron is now only registered when telemetry is active.
• Fix [Forms]: Integration names (Avada, WooCommerce, Elementor, etc.) are no longer passed through WordPress translation. This caused brand names to be incorrectly translated by community language packs — e.g. “Avada” was displayed as “Optionen” on German sites.

2.6.12

• Fix [Settings]: Plugin action link (“Settings” in plugin list) now correctly opens the new React admin UI instead of the removed legacy page.
• Fix [Dashboard]: “View Audit Log” link in the dashboard widget now points to the new Audit Log page instead of the removed legacy page.
• Fix [Navigation]: Old admin page URLs (e.g. admin.php?page=f12-cf7-captcha, f12-cf7-captcha-extended, f12-cf7-captcha-audit-log) now redirect to their React equivalents instead of showing a permissions error.
• Fix [Forms]: Integration presets (WooCommerce, Fluent Forms, JetForm, etc.) no longer default to “enabled” when the setting has not been explicitly saved. Previously, unsaved settings defaulted to enabled, making it appear as though integrations were active even when the corresponding plugin was not installed.
• Fix [Dashboard]: Internal telemetry errors (e.g. TELEMETRY_UNEXPECTED_RESPONSE) are no longer shown in the “Recent Issues” section of the dashboard widget. These technical messages are not actionable by end users.
• Improved [Dashboard]: Protection Score widget is now more compact — score circle reduced from 120px to 72px, stats displayed beside the circle instead of below, and module list uses smaller type for a tighter layout.
• Improved [Settings]: Added descriptive help text to all numeric fields in Advanced Settings (IP Rate Limiting, Content Rules, Mail Log Retention, Block Log Retention, Audit Log Retention) so users understand what each value controls.
• Improved [Cleanup]: Every cleanup action now shows a description below the button label explaining exactly what it does (e.g. “Removes log entries older than 3 weeks”).

= 2.6.11 …