2FA does not work

Hello. What version of BotBlocker do you have installed?

How blocking actually works today

The database is the source of truth for all blocks (IP rules, hot bans, etc.), but the database is not queried during request processing. Whenever a block is added or expired, the plugin regenerates plain PHP files (ip.php, hot-bans.php, settings.php, …) in the protected uploads/botblocker/data/ directory. The shield reads those generated files directly – and they’re also covered by opcache, so the read is just an opcode-cached return array(…).

So per-visitor cost is a static file read, not a MySQL query. This also makes blocking possible before WordPress even loads (our Early Init layer runs from wp-config.php with raw PHP – at that point there is no WordPress, no plugins, and no Redis client). That early layer is the strongest anti-bot guarantee we have, and it fundamentally depends on the generated files.

Why Redis can never be the block store

1. Redis is volatile, blocks are not. Redis can lose everything on restart, OOM eviction, or a misconfigured maxmemory policy. Permanent IP bans and security state must survive restarts. A cache that silently forgets bans is worse than no cache at all.
2. Most hosting has no Redis. The overwhelming majority of WordPress sites run on shared hosting with MySQL only. If the blocklist lived in Redis, the core protection would simply not work there. A security plugin cannot make its primary enforcement depend on an optional extension. (This is also why it can’t be “enabled by default” – on most servers there is nothing to enable.)
3. 50k rows in MySQL is not a problem. An indexed 50k-row table is trivial for MySQL; even 500k is fine. And since the hot path never touches the DB, those rows cost nothing per request. The “inefficiency” you’re seeing isn’t in lookups – it’s just storage, which is what the DB is for.

What Redis is actually used for
Where Redis/Memcached exist, we use them as an optional acceleration layer for counters, transients and cache data – never for correctness-critical state. The plugin detects the environment and degrades gracefully to MySQL transients when no Redis is present.
In short: blocks → DB (source of truth) → generated PHP files → file-based enforcement at all three layers, no DB queries on the request path. Redis stays an optional speed-up for non-critical data, and the blocklist will always remain durable, portable, and shared-hosting-safe.