Parhum Khoshbakht

Hi @blackbird69 ,

Thanks for the extra detail — pasting an IP that’s clearly visible in the Access Log and getting “No matching options found” isn’t right, and “starts with” failing on a known-present IP confirms something’s off. That’s on us, not a UX thing.

Could you forward the video from Gmail over to support at wp-slimstat.com ? I’ll pick it up from there and reply directly — that’s the right inbox for this kind of deeper debugging and it keeps everything tracked in one place.

Once I see the repro I’ll dig in and follow up here with what we find.

Thanks for sticking with it.

Fantastic — glad to hear it’s working on your end! Thanks again for the clear bug report; it made the fix a lot easier to nail down.

Marking this one as resolved. Don’t hesitate to open a new thread if anything else comes up.

Hi @thefriendlancer ,

Thanks for the detailed report and for testing on both PHP versions.

The jump from PHP 7.4 to 8.3 is a big one – PHP 8.0 removed several functions that older code relied on (like each() and create_function()), and any plugin still using them will crash with a 500 error. We’ve cleaned all of these out in recent releases. Version 5.4.11 has been verified compatible with PHP 8.3.

Could you check which version of SlimStat you’re running? You’ll find it under Dashboard > Plugins. If it’s anything older than 5.4.x, updating to 5.4.11 should fix this. You can update from the WordPress admin (Plugins > Update) or by uploading the latest version via FTP to overwrite the existing install.

If you’re already on the latest version and the 500s persist, the next step would be to check the PHP error log. The screenshot you shared shows the HTTP access log (the 500 status codes), but the actual PHP error message that tells us exactly what went wrong lives in a different log. Add these two lines to your wp-config.php, reload a page, then check wp-content/debug.log:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

Share the SlimStat-related lines from that file and we’ll pinpoint the exact issue.

Hi @blackbird69 ,

Just a quick update — the auto-refresh fix is now included in the stable 5.4.11 release, which you can grab through the regular WordPress update screen (Dashboard → Updates). No need to use the dev build anymore.

Along with the refresh fix, 5.4.11 also brings improvements to pagination, bot detection, and report accuracy — full details in the changelog.

Thanks again for reporting this one. Let us know if everything’s working as expected on your end!

Hi @blackbird69 ,

Thanks for flagging this — you’re right, the countdown was stuck at 60 seconds no matter what value you entered in Settings → Reports → Auto Refresh. A bug in the JavaScript scheduler was ignoring the saved interval entirely.

We’ve fixed this in the upcoming 5.4.10 release. The auto-refresh now correctly uses the interval you set, and we also added a few quality-of-life improvements: it pauses when you hover over the Access Log or switch tabs, and your scroll position is preserved across refreshes.

We have a development build ready if you’d like to test it before the official release — you can grab it here: https://wp-slimstat.com/wp-content/uploads/2026/04/wp-slimstat-5.4.10.zip . Please note this is a development version. To install it, go to Plugins → Add Plugin → Upload Plugin, choose the wp-slimstat-5.4.10.zip file, and activate it. It will replace your current version.

We’d really appreciate your feedback on whether it solves the issue on your end.

Thank you so much, Andy – this review really made our day! You’re absolutely right that the combination of plugins, servers, and configurations makes every setup unique, and your patience through all that troubleshooting helped us ship fixes that benefit everyone.
We appreciate the kind words and the years of loyalty. Here’s to many more smooth updates ahead!

That’s great to hear, @tkbuhler — thanks for confirming!

We just released v5.4.8 today with a number of additional fixes, including improvements to session cookies and client-side tracking across all upgrade paths. If you haven’t updated yet, it’s worth grabbing that one too.

Really appreciate you taking the time to report this and follow up. We’re marking this as resolved. If anything else comes up, don’t hesitate to open a new thread.

Hi @alabasterized ,

Thank you for confirming the Daily chart fix works.

On fingerprints — we found and fixed the root cause. The browser fingerprinting library (FingerprintJS) was upgraded from v3 to v4, but one required API call was missing internally, so fingerprint data was never actually generated. This is now fixed in 5.4.8.

Before installing, I want to clarify what fingerprints look like in the Access Log versus hashed IP addresses, since they can look similar:

Hashed IP Address — the long hex string, e.g., c598436c1bb1bda046e... This appears when “Hash IP Addresses” is enabled under Settings → Tracker → Data Protection. It’s a 39-character hash and clicking it filters by “ip address equals”. This is NOT a fingerprint — it’s your visitor’s IP run through a daily privacy hash.

Browser Fingerprint — the short code badge, e.g., 01e5a617 This appears as a small monospace code in the visit header row. Hovering shows the full value, and clicking it filters by “fingerprint equals”. This identifies a specific browser regardless of IP address.

Here is how the Access Log looks with both fingerprints and hashed IPs visible:

Here is the development build with the fingerprint fix:
https://wp-slimstat.com/wp-content/plugins/wp-slimstat-5.4.8.zip
Please install on a staging site or after a full backup.

After installing:

1. Clear your cache if you use any caching plugin (WP Rocket, W3TC, LiteSpeed, etc.) or server-level page cache
2. Visit a few pages in an incognito/private browser window (not logged in)
3. Go to SlimStat → Access Log — new anonymous visitor rows should now show the short fingerprint code badge

For fingerprints to work, verify these settings under SlimStat → Settings:

• Settings → General tab → Tracker section → Tracking Mode: set to “Client” (not “Server”)
• Settings → Tracker tab → Consent Management → GDPR Compliance Mode: Off (you confirmed this)
• Settings → Tracker tab → Data Protection → Anonymize IP Addresses: Off (you confirmed this)

If fingerprints still don’t appear after installing 5.4.8 and clearing cache, please share:

• Your WordPress version and PHP version
• Whether Tracking Mode is set to “Client” or “Server”
• A list of active caching or security plugins

That will help us pinpoint exactly where the issue is. We were not able to reproduce the problem on our end with GDPR off and Anonymize IP off — the fingerprints generated correctly — so it may be environment-specific.