Init Void Shield – Zero-DB, Honeypot, Anti-Spam

FAQ

Does this work with page builders or custom comment forms?

The plugin hooks into comment_form_after_fields. If your theme uses a custom form, you may need to adjust the hook or manually call the render function.

Can I use this alongside Akismet or other anti-spam plugins?

Yes. Init Void Shield acts as the first line of defense. Other plugins can serve as a secondary layer.

Will this block legitimate users?

No. Logged-in users are bypassed by default on the comment form. Guests only need to wait a few seconds between page load and submit — something every human naturally does.

Can I force verification for logged-in users too?

Yes. Enable Apply to Logged-in Users in the settings if your site has open registration or untrusted members.

Does this protect comments submitted through the REST API?

Not by default. The core layers only run on the classic comment form (preprocess_comment); comments posted directly to wp/v2/comments never carry a honeypot or JS token, so those checks don’t apply. The optional “Block REST API Comments” setting is available to close that endpoint entirely if you do not use a headless app or other legitimate REST client for comments.

Are the WordPress login/registration/lost-password guards enabled by default?

No, all three are off by default since they guard authentication itself. Turn them on individually under WordPress Core Forms in the settings, and confirm your own login flow still works afterward. Each covers WordPress’s own default form markup at wp-login.php, and the login guard also covers wp_login_form() when used on the front end (e.g. a widget or theme template), unless you set Login Guard Scope to “wp-login.php only” — see the next question. A custom login page/plugin, or Multisite’s wp-signup.php registration flow, renders different markup and isn’t covered. Each guard can also be force-disabled per request with a dedicated filter (init_plugin_suite_void_shield_skip_login_verification, ..._skip_register_verification, ..._skip_lostpassword_verification), which takes priority over the settings-page toggle.

What is Login Guard Scope?

By default (“Everywhere”), the Login Guard protects both the native wp-login.php form and any front-end wp_login_form() usage (e.g. a custom login page, widget, or modal). If that front-end form lives on a page your cache plugin might serve stale, switch the scope to “wp-login.php only” to leave it entirely unguarded rather than risk a real visitor’s login being rejected — the native wp-login.php form stays fully protected either way. This uses the Referer header as a heuristic to tell the two forms apart, which a determined bot could spoof, so it’s a deliberate trade-off: only switch away from “Everywhere” if you’ve hit this specific caching situation.

Are the Contact Form 7 / WPForms / Gravity Forms integrations enabled by default?

No. Each is off by default and only takes effect if the matching plugin is active — the settings page shows a “detected / not detected” status next to each toggle.

Are the WooCommerce / bbPress / BuddyPress integrations enabled by default?

No, same as the other integrations: each is off by default and only takes effect if the matching plugin is active. WooCommerce guards the “My Account” registration form; bbPress guards the New Topic and Reply forms; BuddyPress guards the registration (signup) form. The Multisite signup guard (wp-signup.php) only has an effect on a Multisite install and is also off by default.

Why aren’t Ninja Forms or Forminator supported?

Both build their forms client-side and collect submitted data through their own JavaScript field model rather than serializing the whole <form> element, so a honeypot field simply appended to the page would not reliably be sent to the server — it would look like protection without actually doing anything. Both also already ship their own built-in honeypot field. Support may be reconsidered if a reliable hook becomes available.

What is the Maximum Token Age setting?

Each guard issues a signed token good for a limited time window: too fast (below Minimum Submit Time) and too old (above Maximum Token Age) are both rejected. The ceiling exists so a token cannot be captured once and replayed indefinitely; the default of 1 hour is generous enough for a visitor who takes their time filling out a form. Increase it (up to 30 days) if legitimate visitors on your site routinely take longer than that, or if your site uses full-page caching — see the next question.

My site uses aggressive full-page caching and legitimate comments are being rejected as “expired” — what do I do?

On a cached page, the time token baked into the HTML reflects the moment the page was cached, not the moment a real visitor loaded it. If your cache lifetime is long, that gap can exceed the Maximum Token Age. Two options, either works on its own: raise Maximum Token Age to comfortably cover your cache lifetime, or enable Lazy Fetch under Advanced Protection, which refreshes the token client-side right after the page truly loads, so timing is always measured from the real visit regardless of cache age.

What does Lazy Fetch do, and is it safe?

When enabled, a small same-origin JavaScript request (no jQuery, no external service) fetches a fresh, correctly signed time token right after the page loads, and overwrites the one baked in at render time. It’s stateless — the endpoint only recomputes the same signed hash the page would already have shown, and is only registered at all while Lazy Fetch is enabled. If the request fails, or JavaScript is unavailable, the original baked-in token is used as-is, exactly like before Lazy Fetch existed — so enabling it can only help, never introduce a new failure mode. Off by default; applies to every guarded form, not just comments.

I updated from an older version and my Minimum Submit Time / JS Token Delay no longer behaves the way I remembered — why?

Versions before 1.4 had a bug where these two settings were saved correctly but never actually read back during verification, so the plugin always silently enforced the defaults (3 seconds / 1000ms) no matter what was configured. 1.4 fixes this, so a custom value you set earlier may now be enforced for the first time. This is a bug fix, not a new restriction — just double-check both values on the settings page after updating.

What does “Require Real User Interaction” do?

When enabled, a submission is only accepted if the browser recorded at least one real mouse, keyboard, touch, or scroll event before the JS token fires. It targets bots that wait out the JavaScript Token Delay instead of a real page visit. It’s off by default and works best paired with a JS delay of at least 1-2 seconds.

Can I change the honeypot field names?

Yes. Set a Custom Field Prefix under Advanced Protection. Field names are still dynamically derived per context and site salt on top of that prefix.

Does the headless-browser detection call any external service?

No. It only reads navigator.webdriver and the browser window size on the visitor’s own device — no external requests, no tracking.

What does the statistics feature store?

Only aggregate counters (a total, a breakdown by channel, a breakdown by block reason, and a last-blocked timestamp) in one non-autoloaded option. No per-submission logs, IP addresses, or personal data are recorded. It can be turned off or reset from the settings page at any time.

Is the Dashboard widget on by default?

No. Enable Show Dashboard Widget under Statistics. It’s only visible to users who can manage options, and only shows the same aggregate counters as the settings page (no per-submission data).

Can developers customize the behavior?

Yes. See the Filters section below for the full list, or the documentation on GitHub for more detail.