Parhum Khoshbakht

Hi @guenther999 ,

Thanks for the detailed report — the stack trace and system info made it easy to pinpoint the problem.

You’ve hit a confirmed bug in 5.4.1. The intval() error in the REST endpoint (/slimstat/v1/hit) happens because WordPress passes three arguments to sanitize callbacks, but PHP 8’s strict mode rejects the extra argument. Every pageview triggers this fatal error, which explains the high database load your hoster flagged — the repeated failed requests put constant pressure on the server.

We’ve already fixed this in v5.4.2, which is releasing very soon. The fix replaces the problematic intval call with a proper wrapper that handles WordPress’s callback signature correctly. The update also includes a new database index on the stats table that should further improve query performance on large sites like yours.

Once v5.4.2 is available, updating from the WordPress plugins page should resolve both the error and the server load. You can safely reactivate SlimStat after updating.

Best regards,
The SlimStat Team

Hi @senribb,

Thanks for the detailed report — the error code and shortcode examples made it much easier to investigate.

We tested your exact shortcode syntax against the codebase and confirmed the shortcodes are working correctly. The root cause is error 101 — it’s blocking the tracker from saving new visits, which is why all your counts show 0.

Here’s what’s happening: error 101 means the security signature embedded in your pages no longer matches the key stored in SlimStat’s settings. This breaks every time the plugin is reinstalled, because a new key is generated — but your pages still serve the old signature. Even without a caching plugin, most hosting providers run server-level caching (Nginx FastCGI cache, LiteSpeed cache, Varnish, or Cloudflare) that you wouldn’t see from WordPress.

Here’s how to fix it:

1. Ask your hosting provider to purge the server-side page cache for this site completely
2. Clear your browser cache (or test in a private/incognito window)
3. Visit a few pages on your site
4. Wait 2-3 minutes, then check SlimStat’s dashboard — you should see new visits appearing

Once new visits show up, your shortcodes will return the correct numbers again.

Since your other site on the same server works fine, this confirms it’s a per-site cache issue — that site likely had its cache cleared naturally or wasn’t cached when the plugin was reinstalled.

Also, if you have GDPR Compliance Mode enabled, SlimStat won’t track any visits until the visitor accepts the consent banner. If you want the banner completely off, make sure GDPR Compliance Mode is set to Off under SlimStat > Settings > Consent Management. With it on, visitors who haven’t accepted the banner won’t be tracked — so your shortcode counts would also stay at 0 for those visits.

We’re tracking this at: https://github.com/wp-slimstat/wp-slimstat/issues/176

Let us know if purging the cache resolves it!

• This reply was modified 5 months ago by Parhum Khoshbakht.

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 @1waytoheaven and @silenx ,

We’ve just released version 5.4.1, which fixes the consent banner bug. Sorry it took a bit — and thanks for your kind words, that really means a lot to us.

You should see the update available in your Plugins page now. Once you update, you can reactivate Slimstat and the banner won’t show up anymore.

Just to confirm — if you want the banner completely off, make sure GDPR Compliance Mode is set to Off under SlimStat > Settings > Consent Management. With v5.4.1, that setting will work as expected again.

Thanks again for reporting and confirming this — it helped us get it sorted quickly!

Best,
Parhum

Thanks for the kind words and for reporting this, @qerghgfjkgk !

You’re right — when a site is behind Cloudflare, the geolocation can resolve to the Cloudflare data center’s country instead of the visitor’s real country. We’ve identified the root cause and already scoped the fix (#150).

This is planned for the next release (v5.4.2), which will properly detect the real visitor IP via Cloudflare headers and use it for country detection. Stay tuned!

Hi @vijaiya ,

Good news — we’ve just released version 5.4.1, which fixes the consent banner bug you reported. The banner will no longer appear when GDPR Compliance Mode is turned off.

Please update Slimstat to v5.4.1 from your Plugins page, and the issue should be resolved right away.

Thanks again for reporting this — it helped us catch and fix it quickly!

Best,
Parhum

Hi @1waytoheaven and @silenx ,
Thanks for reporting this — and for confirming it on multiple setups, that really helps us narrow it down.

You’re right, this is a bug in 5.4.0. The consent banner shouldn’t appear when GDPR Compliance Mode is turned off, but a change in the recent update accidentally left it showing regardless of that setting. This is on us.

We’ve already developed a fix and it’s tracked here: https://github.com/wp-slimstat/wp-slimstat/issues/140

We’ll get the next release out as soon as we can.
Sorry about the hassle, and thanks for your patience!

Could you please share with us the error log from your site, as well as the technical site information available under Tools → Site Health → Info?

It would also be very helpful if you could temporarily enable WP_DEBUG so we can see any error messages that might appear.

Don’t worry — we’ll guide you through the next steps based on what we find.
Thanks a lot for your help!