IniLerm

Hi @martje65,

Great question!

This feature applies to ALL users attempting to access the specific endpoints (wp-login.php and xmlrpc.php).

Because this block happens at the firewall level before WordPress processes the login (and before we know who the user is or what their role is), it restricts the entire login page to the selected countries.

Recommendation for your sites:

• Standard Websites / Blogs: This is a perfect security measure to lock down the admin panel to your home country.
• WooCommerce / Membership Sites: If you have international customers or members who need to log in from other countries, do not use this specific feature, as it will block them from accessing the login page. Instead, rely on our other protections (like Geo-Challenge, 2FA for Admins, and Failed Login blocking) to secure your global user base.

I hope this clarifies how it works!

Hi @truden,

Thank you for replying and clarifying that!

That piece of information (“locked out immediately on plugin activation”) changes everything. A fresh installation should never lock you out immediately, as all strict blocking features (like Country Blocking or Login Restriction) are disabled by default, and the Setup Wizard actively attempts to whitelist your IP.

As the developer, I want to investigate this immediately to ensure it doesn’t happen to anyone else. If you are willing to share a few technical details, it would be incredibly helpful for debugging:

1. What kind of block did you see? Did you see a white screen with our plugin’s logo and “Access Restricted” message? Or was it a generic server error (like a 500 Internal Server Error or a blank white screen)?
2. Environment: Are you using Cloudflare or any other reverse proxy/CDN?
3. Previous Installation: Was this a brand new installation from the WordPress repository (v8.8.9), or did you previously have an older version of the plugin installed and were re-activating it?
4. Other Security Plugins: Were there any other security or caching plugins active at the moment of activation?

I completely understand if you’ve moved on, but if you have a moment to answer any of those questions, it would give me exactly the clues I need to track down this edge-case bug.

Thank you again for your time and feedback!

Best regards,

@inilerm

Hi Oleg (@olegchuvakin),

I am truly touched by your words. Thank you so much for this beautiful 5-star review.

You perfectly described the reality of running a website today: the constant, unseen battle against automated bots trying to tear down what creators have built.

My goal from day one was exactly what you felt: to build a reliable, enterprise-grade shield and make it accessible to everyone for free, because website security should be a fundamental right, not a luxury.

Knowing that Advanced IP Blocker is providing you with peace of mind is the greatest reward I could ask for.

May the Universe watch over your projects as well, my friend! Thank you for being part of this community.

Warmest regards.

Hi @cousineddie,

I’m following up on this issue since we haven’t heard back regarding the browser console log.

Because we haven’t been able to replicate this behavior on our test servers (where we also run Elementor, RankMath, and heavy backend editors without issues), I suspect this is a highly specific conflict related to how background requests (AJAX/REST API) are being handled or intercepted in your particular environment.

To help you resolve this quickly—and to leave this as a helpful guide for the community—here is a step-by-step troubleshooting process for when backend editors or analytics graphs fail to load:

1. Isolate the Plugin’s Protections (Global Exclusions) Sometimes, aggressive security settings can accidentally block internal WordPress processes (like the ones RankMath or the WP Editor use to fetch data). We have a feature designed specifically to prevent this. Please go to Security > Settings > General and look for the “Global URL Exclusions” text box. Add the following lines (one per line):

/wp-admin/admin-ajax.php
/wp-json/
/wp-json/rankmath/
/wp-json/elementor/

etc ..

Why this works: This tells Advanced IP Blocker to completely bypass Rate Limiting, Signature Challenges, and 404/403 monitoring for these essential WordPress communication channels, which usually resolves AJAX timeouts instantly.

2. Check your WAF and Honeypot Rules If you have added custom rules to the Web Application Firewall (WAF) or the Honeypot URLs, double-check them. A broadly defined rule (for example, blocking any URL containing the word admin or api .. etc) might be unintentionally catching legitimate requests from your SEO plugins or the WordPress editor.

3. Server-Level or Third-Party Conflicts Since you mentioned your .htaccess file being continually modified, it’s worth noting that AIB only writes to .htaccess when a new threat is detected (if the Server-Level Firewall feature is enabled). However, if the AJAX timeouts persist even after adding the exclusions in Step 1, the block might be happening before the request even reaches our plugin:

• Other Security Plugins: Are you running another security plugin simultaneously? Two firewalls can often conflict.
• Cloudflare / Hosting WAF: Check your Cloudflare Firewall Event logs or your hosting provider’s WAF logs (like ModSecurity). Very often, heavy AJAX requests containing HTML payloads (saving a post in an editor) are blocked by Cloudflare’s Managed Rules, resulting in the exact timeout errors you are seeing.

Please try adding the Global URL Exclusions mentioned in Step 1 first. If that resolves it, we know the issue was an overly aggressive setting. If it doesn’t, I highly recommend checking your Cloudflare/Server logs to see what is dropping the connection.

Let me know how it goes or if you need help analyzing any server logs!

Hi @cousineddie,

Thank you for reporting this in detail. What you are experiencing is an environment-specific conflict with the Server-Level Firewall (.htaccess protection) rules, not a random bug. Let me explain what the log means and how we can definitively fix it.

1. About the Audit Log “fim_alert”: The message File integrity changes detected: .htaccess (modified) simply means that our File Integrity Monitor detected that something changed your .htaccess file. This could be our own plugin updating block rules, or another plugin (like a caching or SEO plugin) rewriting it.

2. Why are things breaking? When the .htaccess file gets updated and includes Advanced IP Blocker’s “Server-Level Firewall” rules, it seems your specific server environment (perhaps LiteSpeed, or an active ModSecurity rule on your hosting) is misinterpreting the security directives. This is causing your server to return “403 Forbidden” errors or block access to legitimate background files (like the JavaScript needed for Elementor, RankMath, or the WP Editor to load). Because the files get blocked at the server level, the browser throws AJAX/Connection errors.

How to get a permanent fix (The diagnostic steps):

First, to stop the immediate frustration and get your site working while we diagnose, please go to: Security > Settings > General and turn OFF the “Server-Level Firewall (.htaccess)” feature. This will immediately stop AIB from writing security rules to that file. We recommend using the “Cloud Edge Defense (Cloudflare)” feature instead, as it provides the same performance benefits without touching your server files.

If you want to keep using the .htaccess firewall, we need your help to isolate exactly which rule is causing the conflict on your server. To do this, we need to see the exact errors your browser is encountering when the site “breaks”.

Please follow these steps:

1. Turn the “Server-Level Firewall (.htaccess)” back ON (so the issue replicates).
2. Go to your WordPress Dashboard (or the Elementor Editor where the issue occurs).
3. Open your browser’s Developer Tools Console:
   • Windows/Linux: Press Ctrl + Shift + J (Chrome) or Ctrl + Shift + K (Firefox).
   • Mac: Press Cmd + Option + J (Chrome) or Cmd + Option + K (Firefox).
4. With that Console panel open, force refresh the page (Ctrl + F5 or Cmd + Shift + R).
5. Look at the Console tab. You will see several lines of error text (usually in red), indicating which files failed to load (e.g., Failed to load resource: the server responded with a status of 403 Forbidden).
6. Please copy and paste those exact red error lines here.

Those errors will tell us exactly which file or API endpoint your server is blocking, allowing us to adjust the rules for environments like yours.

Standing by for your results!

Best regards.

Advanced IP Blocker Team

A useful guide for these cases:

How to Unblock Yourself (Locked Out)

https://advaipbl.com/how-to-unblock-yourself-locked-out/

Hi @muttmutt,

This is absolutely incredible work. Thank you so much for sharing your “Defense Stack” with the community!

I have reviewed your GitHub repository, and your strategy of combining Cloudflare’s ASN blocking at the edge with Advanced IP Blocker’s Honeypot and Signature Engine at the application level is textbook perfection for a “Defense in Depth” architecture. Seeing those stats (65% blocked at the edge, 160 IPs caught by AIB) is the best proof that this setup works.

We are honored to be the core component of your security stack. Contributions like this are what make the WordPress community so special.

Please, go enjoy your time underwater! You have earned a serious break. The community (and we) appreciate your effort immensely.

Best regards,

Advanced IP Blocker Team