Nahnu Login Shield

No. OOPSpam is one of seven CAPTCHA provider options. All other providers and all other features work independently.

No. Assets load only on wp-login.php and any pages you opt into via the Integrations tab. The JS check uses a tiny inline script with no external request. Geo lookups from CDN headers are zero-latency. API fallback results are cached per IP for a configurable period. If you opt in to the early-block mu-plugin, it turns away locked-out IPs before WordPress fully loads.

All providers fail open. A network or API error never locks out legitimate users.

It hooks specifically into WordPress login actions and standard WooCommerce and form-plugin hooks. If another plugin hooks the same actions it may conflict. Open a support thread with details if you see an issue.

Yes. Set the provider to None. Geo-blocking, brute-force lockout, honeypot username trapping, the JS presence check, and 2FA all work independently of CAPTCHA.

Yes. The WooCommerce My Account login, registration, lost-password, checkout, and order-tracking forms each have their own toggle in the WooCommerce section of the Integrations tab.

Two options. First, add define( 'NAHNLS_BYPASS_IP', 'your.ip.address' ); to wp-config.php (above the "That's all, stop editing" line). It accepts a comma-separated list of IPs and CIDR ranges, and exempts them from lockouts, the IP blocklist, geo blocking and the early-block rate limit - no deactivation needed. Second, rename the plugin folder from nahnu-login-shield to _nahnu-login-shield via SFTP, which deactivates it. If you are stuck at the two-factor step instead, see the next question.

Yes, and it is a good idea: usernames are public (author pages, feeds, the REST API), so bots try them. Add your username to the Honeypot list on the Lockout tab and sign in with your email address from then on. Anyone who tries the username is locked out like a bot. Email addresses of real accounts are never blocked, so patterns like admin@* do not affect your own sign-in. The Lockout tab lists which entries are real accounts and reminds you if your own username is on the list. If you get locked out anyway, add define( 'NAHNLS_DISABLE_HONEYPOT', true ); to wp-config.php (above the "That's all, stop editing" line) to switch the honeypot list off, sign in, fix the list, then remove the line. To clear an IP that is already locked, also see the question above.

When two-factor authentication is on, every sign-in asks for a code, and email codes are the baseline. If the email does not arrive (a mail problem on the server, spam filtering), first try a backup code or "Email me a code" again. If that does not help, add define( 'NAHNLS_DISABLE_2FA', true ); to wp-config.php (above the "That's all, stop editing" line). This switches the 2FA check off for everyone, so you can sign in with just your password; the plugin's settings page shows a notice while it is set. Fix email delivery (an SMTP plugin usually does it), add an authenticator app on your Login & security page so you are not dependent on email, then remove the line. Note: NAHNLS_BYPASS_IP does NOT bypass 2FA - it only exempts addresses from lockouts, the IP blocklist, geo blocking and the early-block rate limit.

Mostly yes. Every protected form carries a hidden security token that lives about a day. On page load the plugin's small script fetches a fresh token (one request to admin-ajax.php), so pages served from a full-page cache keep working as long as JavaScript runs - including cached blog posts with a comment form. Without JavaScript, a cached copy of the form older than a day fails the security check and asks the visitor to reload. Login, registration and My Account pages should still be excluded from full-page caching (WooCommerce requires this anyway). Developers can lengthen the token life with the nahnls_form_nonce_life filter.

It is not tested on multisite and is not recommended for network activation.

It falls back to one of two free IP geolocation APIs (freeipapi.com or ipinfo.io) with a configurable cache. CDN headers are always checked first and take priority.

Open a support thread or submit a request at https://nahnuloginshield.com/support/. Bricks Builder, SureForms and WordPress comments are the supported integrations today; anything else can be wired up through the developer API (docs/API.md) while a request is considered.

The mu-plugin is optional and opt-in. Nothing is copied until you, as an administrator, click Install early-block mu-plugin on the General tab. That button copies nahnls-early-block.php from the plugin folder into your must-use plugins directory (WPMU_PLUGIN_DIR, normally wp-content/mu-plugins/). The file checks whether the requesting IP is locked out or rate-limited and, if so, sends a 403/429 response before WordPress fully loads — dramatically reducing server load during bot floods. The General tab shows whether it is installed, not installed or outdated; after a plugin update you are offered an Update mu-plugin button (it is never refreshed automatically). Clicking Remove deletes the file, and it is also removed on plugin deactivation and deletion. If the directory is not writable, the settings page shows manual copy instructions instead. The per-IP rate-limit counters the mu-plugin uses are tiny text files stored inside your WordPress uploads directory at wp-content/uploads/nahnu-login-shield/ratelimit/ (protected by an index.php and .htaccess; files older than five minutes are pruned automatically). Nothing is written outside the WordPress installation; the folder is deleted when the plugin is uninstalled.

The per-username lockout catches this: if the same username is attempted from too many different IPs within the time window, the username itself is locked regardless of IP. Adding common targets (admin, administrator, root) to the Honeypot username list gives the strongest protection — one attempt from any IP is enough to lock both the IP and the username globally.