Parhum Khoshbakht

Hi @ktsinfo0076 ,

Just a quick heads-up — we’ve released version 5.4.6.

We heard from many users that upgrading to the 5.4.x series caused unexpected issues: visitor counts dropping to zero, IPs being masked without permission, and a consent banner showing up on sites that never enabled one. This release fixes all of that. After updating, your site should work the way it did before 5.4.0 — no manual steps required.

If you’re using a caching plugin, please clear your cache after updating.

Once you’ve updated, visit a few pages on your site and check the Access Log to confirm new data is being recorded. If anything looks off, we’re here to help.

Hi @soolee ,

Thanks for sticking with us through this — we know the last few updates have been rough, and your patience (and bug reports!) genuinely helped us get to the bottom of it.

We just released version 5.4.6, which is a comprehensive fix for the issues that came with the 5.4.x line. Visitor counts dropping to zero, IPs being masked without permission, the consent banner appearing on sites that never enabled it, and the Access Log display problems — all addressed. After updating, your site should work the way it did before 5.4.0, with no manual steps required.

If you’re running a caching plugin (WP Rocket, W3 Total Cache, etc.), clear your cache after updating so the new tracker script is served fresh.

Once you’ve updated, visit a few pages on your site and check the Access Log — you should see new data coming in right away. If anything still looks off, we’re right here.

Hi @alabasterized ,
Update the plugin to v5.4.6!

We heard you — upgrading to 5.4.x broke tracking for many of you. Visitor counts dropped to zero, IPs were masked without your permission, and a consent banner appeared on sites that never asked for one. This release fixes all of that. After updating, your site works the way it did before 5.4.0 — no manual steps required.

If you have a caching plugin, clear your cache after updating.

Then visit a few pages and check the Access Log to see new data recorded. If you run into anything, we’re right here.

Hi @soolee ,

Thanks for the follow-up — glad the IP and geolocation issue is sorted!

We’ve actually addressed the Access Log display size in version 5.4.5, which was released today. The dashboard widget height has been increased from 320px to 500px, so you should see roughly twice as many entries at a glance. All your entries are still loaded — the widget scrolls — but the visible area is now much larger.

Could you update to v5.4.5 from your WordPress dashboard and let us know if the Access Log looks better? If the window still seems too small after updating, it’s possible a theme or another plugin’s CSS is overriding our styles — just let us know and we’ll help troubleshoot.

You can also adjust the number of rows loaded in the Access Log by going to SlimStat → Settings → Reports → “Access Log and World Map” → Rows to Display.

Hi @qerghgfjkgk ,

Thanks for flagging this — we appreciate you sticking with us through the updates.

We hear you: seeing only the proxy IP when you used to see the real visitor IP is frustrating. Here’s what’s likely going on.

Since v5.4.0, we tightened the privacy defaults — GDPR Compliance Mode, Hash IP, and Anonymize IP are now all ON by default. When GDPR is enabled and a visitor hasn’t granted consent yet, we force IP hashing for privacy compliance. That hashing intentionally clears the originating IP (the real one behind your proxy). So even if your proxy is forwarding headers correctly, SlimStat won’t store the originating IP in that scenario.

The quickest fix: head to SlimStat > Settings > Tracker > Data Protection and turn OFF “Hash IP Addresses.” If you also have GDPR Compliance Mode enabled, the originating IP will only appear for visitors who’ve granted consent — that’s by design. If you don’t need GDPR mode at all, turning that off too will restore full IP visibility for everyone.

“Anonymize IP Addresses” is safe to leave ON — it masks the last octet but still preserves both the proxy IP and the originating IP.

Could you let us know what proxy or CDN you’re behind (Cloudflare, Nginx, HAProxy, etc.)? That’ll help us rule out any header-level issues on top of the settings change.

Thanks

Hi @tkbuhler ,

Thanks for the follow-up — we hear you, and we want to get to the bottom of this.

After your report, we wrote a dedicated set of automated tests specifically for user exclusion — covering both the “Exclude WP Users” toggle and the username blacklist, across every tracking transport (AJAX, REST, and even simulated stale-nonce scenarios). All five tests pass: excluded users produce zero rows in the database, exactly as expected.

So the exclusion logic itself is solid, which means something in your environment is likely interfering with how WordPress identifies logged-in users during the tracking request. The most common culprit we see is a page caching plugin (WP Super Cache, W3 Total Cache, LiteSpeed Cache, etc.) or a CDN like Cloudflare — these can serve cached pages where the tracking script doesn’t know you’re logged in, so the server-side exclusion never kicks in.

Could you let us know if you’re running any caching plugin or CDN? That’ll help us narrow it down quickly.

Thanks for sticking with us on this!
Cheers

Hi @toxicum ,

Just a quick follow-up — we’ve since released version 5.4.4, which includes additional stability and geolocation improvements on top of the original fix. If you haven’t already, we’d recommend updating to the latest version through your WordPress dashboard.

If the cron error is gone on your end, we’ll go ahead and mark this thread as resolved.

Feel free to reopen if anything comes up.

Thanks again for the report!

Hi @enjoybeerlife ,

Circling back to confirm this issue has been fully resolved. The translation loading timing fix shipped in v5.4.2 and the latest version is now v5.4.4, which includes additional improvements and fixes.

If you haven’t updated yet, please update to v5.4.4 through your WordPress dashboard — the PHP notice will be gone.

We’re marking this as resolved. If you run into anything else, don’t hesitate to open a new thread.

Thanks for your patience and for reporting this!

Best,
The SlimStat Team