Parhum Khoshbakht

You’re welcome, @baga ! Glad it helped. 😊

@missmikado — if you’ve had a chance to set it up and everything’s working, let us know. Happy to help if anything comes up.

Hi @missmikado and @baga ,

Thanks for reaching out – great question! The FAQ you found describes an older method from SlimStat 5.3 that no longer applies. Since version 5.4, Complianz integration is built in and much simpler – no cookie values needed at all.

Here’s what to do:
1. Install and activate the free “WP Consent API” plugin from wordpress.org (Complianz has built-in support for it).
2. In your WordPress admin, go to SlimStat > Settings > Tracker tab.
3. Under “Consent Management”, turn on “GDPR Compliance Mode”.
4. Set “Consent Plugin Integration” to “Via WP Consent API”.
5. Save. That’s it!

SlimStat will now automatically listen for Complianz consent decisions and only track visitors who’ve given their permission. Nothing to type into any cookie field.

We’ll get that FAQ updated so it doesn’t cause confusion for others. Thanks for flagging it!

Thank you for the kind words, Bob! We’re glad we could get the Browscap issue sorted out together. Your patience through all that testing made a real difference – it helped us improve the fix for everyone. Appreciate you taking the time to share your experience!

Hi @qerghgfjkgk ,

I understand your frustration, and I want to be straightforward with you.

WordPress configurations vary enormously — different PHP versions, caching layers, security plugins, server setups — and some issues are genuinely hard to reproduce. This fingerprint bug, for example, did not surface in our test environment or QA pipeline, which is why it slipped through multiple releases.

We do use AI tools to speed up parts of our workflow — research, testing, code review — but every change, every message, and every release goes through human review. I’m a human, and I’m here to support you.

The real problem is not AI. Our development team changed, and during that transition we introduced regressions that should have been caught. We take responsibility for that. We’re setting up a new workflow with automated E2E testing specifically to prevent these kinds of issues from happening again.

The fingerprint bug has been found and fixed — the browser fingerprinting library was upgraded from v3 to v4, but a required API call was missing, so fingerprint data was silently never generated. That’s now resolved in the latest development build.

If you ever want to give the plugin another try, the latest development build is available here:
https://wp-slimstat.com/wp-content/plugins/wp-slimstat-5.4.8.zip

Also, please drop us an email at support at wp-slimstat.com — we’d like to send you a small gift for sticking with us and reporting this directly.

No pressure — I understand if you want to stay on 5.3.5 for now. But if you do try the new version and run into anything, I’m right here.

Hi @alabasterized and @qerghgfjkgk ,

Thank you both for reporting this. I want to address each issue clearly.

@alabasterized , you’re right — the new chart system in 5.4.x auto-detects granularity based on the date range, and for the default 28-day view it picks weekly, giving you just 4 data points. In the development build below, you can now switch the chart to “Daily” using the dropdown, and that choice persists across page loads and sessions — once you switch to Daily, it stays that way.

@qerghgfjkgk , I hear your frustration and I take it seriously. On the fingerprint issue — version 5.4.0 through 5.4.6 had a bug where JavaScript-based tracking was broken on cached sites, which also prevented fingerprint generation since FingerprintJS runs client-side. The build below restores client-side tracking unconditionally, which should bring fingerprints back.

Here’s the development build with these fixes:
https://wp-slimstat.com/wp-content/plugins/wp-slimstat-5.4.7.zip

Please install on a staging site or after a full backup first. Two things to check under Settings → Tracker → Data Protection:

• “GDPR Compliance Mode” should be Off — when it’s On, fingerprints are intentionally skipped until the visitor gives consent (privacy by design).
• “Anonymize IP Addresses” should be Off — when it’s On, fingerprints are silently discarded on the server side even if the browser sends them.

If you’d like to test the new Pro version as well, email us at support at wp-slimstat.com .

After installing, please let me know whether fingerprints are showing up and whether the daily chart selection sticks. If the issue persists, your WordPress version, PHP version, and a list of active caching or security plugins would help me narrow it down.

Hi @dxylott54 ,

Quick heads-up — we’ve just released v5.4.6. If you updated to any 5.4.x version earlier, this one is worth grabbing right away.

We heard from many users that upgrading to 5.4.x broke tracking — visitor counts dropped to zero, IPs were masked without 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’re using a caching plugin (WP Rocket, W3TC, etc.), clear your cache after updating so the new tracker scripts are served fresh. Once 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 @kindnessville ,

Quick heads-up — we just released SlimStat v5.4.6

We heard from many users that upgrading to 5.4.x broke tracking in several ways: visitor counts dropping to zero, IPs masked without permission, and a consent banner appearing 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 use a caching plugin, clear your cache after updating.

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

Cheers

Hi @guenther999 ,

We just released v5.4.6, and we wanted to circle back here because this update addresses the broader issues that came with the 5.4.x line — not just the intval() error you reported, but everything else that went wrong.

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

Since you’re running WP Rocket, please clear your cache after updating the plugin. Then visit a few pages on your site and check the Access Log to confirm new data is being recorded.

If anything comes up, we’re here — feel free to open a new thread.

Best regards,
The SlimStat Team