Bug in latest version

Hi there,
Thanks for flagging this — really appreciate it!

We looked into what you’re describing and found two separate things going on:

The banner showing when GDPR Compliance Mode is OFF — that’s a bug on our end. We recently changed some defaults that accidentally broke this. When you turn GDPR off, the consent banner should disappear completely, but right now it doesn’t. We’re sorry about that — we understand how confusing it is to see a consent prompt that shouldn’t be there. We’ve opened a GitHub issue to track the fix:
https://github.com/wp-slimstat/wp-slimstat/issues/140

The “Via WP Consent API” option being greyed out — that’s actually by design. To use that integration, you’ll need two plugins installed and active:

1. WP Consent API  — this is the bridge that lets SlimStat read consent status
2. A consent banner plugin like CookieYes — this creates the actual consent banner and communicates with the WP Consent API

Once both are active, the “Via WP Consent API” option will unlock, and you can let CookieYes (or another compatible CMP) handle the consent banner instead of SlimStat’s built-in one. While our settings description mentions Complianz as a compatible CMP, it still requires the standalone WP Consent API plugin to be installed separately for the integration to work.

In the meantime, turning GDPR Compliance Mode off should stop our banner from appearing once the fix lands. We’ll get this sorted as soon as possible.

Thanks for your patience!
Cheers

Hi,
Just checking in — hopefully the v5.4.1 update resolved the double consent issue for you. If everything’s working as expected, we’ll go ahead and mark this as resolved.

If the problem persists after updating, feel free to reopen or start a new thread and we’ll dig in further.

Best,
Parhum

Hi @kelogs

Thanks for reporting this, kelogs. A site going unresponsive with 503 errors is serious and we appreciate you narrowing it down to the plugin.

You hit a known performance bug in v5.4.1 where the visit ID generation could overwhelm the database under normal traffic, exhausting PHP workers and causing exactly the 503 pattern you described. We identified the root cause and shipped a fix in v5.4.2.

Please re-enable the plugin and update to v5.4.2 through your WordPress dashboard (Plugins > Updates). That should resolve the 503 errors completely.

Let us know how it goes after the update.

• This reply was modified 1 week, 4 days ago by Parhum Khoshbakht.