Title: Problems with recent updates Last modified: March 16, 2026 --- # Problems with recent updates * Resolved [tkbuhler](https://wordpress.org/support/users/tkbuhler/) * (@tkbuhler) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/) * SlimStat (with recent updates, currently 5.4.3) has seriously deteriorated in the quality of analytics it returns for my site. The biggest problem is that it no longer appears to be excluding bots (etc) from the stats, even with it set to not track these. Also, the tracking is not excluding the types of content i set (such as cpt) to exclude, permalinks i want to exclude, or even users i want to exclude. * Will there be a fix for these issues? If not, this plugin has become much less useful. Viewing 11 replies - 1 through 11 (of 11 total) * Plugin Contributor [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * (@parhumm) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18853746) * Hi [@tkbuhler](https://wordpress.org/support/users/tkbuhler/) , Thanks for flagging this — really appreciate you taking the time to report it in detail. * We investigated all four areas you mentioned (bots, content types, permalinks, and users) and ran a full suite of automated tests against v5.4.3. Here’s what we found: * **Bot exclusion, permalink exclusion, and user exclusion are all working correctly** in v5.4.3. If you have **“Ignore Bots”** enabled under **_SlimStat > Settings > Exclusions_**, crawlers detected by Browscap are filtered out. Same for permalink patterns in “Resources to Ignore” and user exclusion settings — they’re functioning as expected. * **Custom post type (CPT) exclusion** — this is where we found the problem, and it’s on us. To exclude a custom post type like “product”, you need to enter it as `cpt:product` (with the `cpt:` prefix) in the “Content Types” exclusion field. The settings UI didn’t explain this, so entering just `product` would silently fail to exclude anything. That’s confusing and shouldn’t have happened. * We’ve already fixed the settings description to make the `cpt:` prefix requirement clear, and we’re tracking this under our GitHub issue: [https://github.com/wp-slimstat/wp-slimstat/issues/233](https://github.com/wp-slimstat/wp-slimstat/issues/233) * **To fix it on your end right now**: go to _SlimStat > Settings > Exclusions > Content Types_, and change any custom post type entries to use the `cpt:` prefix( e.g., `cpt:product` instead of just `product`). * Could you try that and let us know if the CPT exclusion starts working for you? That’ll help us confirm the fix covers your setup. * Thanks for your patience! Cheers * Thread Starter [tkbuhler](https://wordpress.org/support/users/tkbuhler/) * (@tkbuhler) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18854089) * Hello… thanks for your help with this. I’ll try the CPT setting in the exclusions. * As for my other problems, i’m definitely still having the issue with User exclusions in particular. I do have WP Users set to be excluded, and in addition i also have the specific usernames excluded from tracking. Despite these settings, Slimstat is still showing the tracking of this logged-in user on the site (this is a recent problem for me… until a recent update this wasn’t the case). * Plugin Contributor [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * (@parhumm) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18855026) * Hi [@tkbuhler](https://wordpress.org/support/users/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 * Thread Starter [tkbuhler](https://wordpress.org/support/users/tkbuhler/) * (@tkbuhler) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18855373) * Thanks for your help… i don’t currently have a caching plugin or CDN running for my site. * Also, i’ve just noticed that a CPT exclusion i have set (cpt:attachment) is still tracking hits for that content type on my site. * Plugin Contributor [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * (@parhumm) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18855664) * Hi [@tkbuhler](https://wordpress.org/support/users/tkbuhler/) , * Thanks for confirming — that rules out caching as the cause, and we appreciate you staying with this. * Two updates: **cpt:attachment** — this one is on us. We’ve confirmed it’s a bug and filed it here:[https://github.com/wp-slimstat/wp-slimstat/issues/236](https://github.com/wp-slimstat/wp-slimstat/issues/236) * The short version: WordPress handles attachment pages differently from other content types internally, and our exclusion code wasn’t accounting for that difference, so cpt:attachment never matched regardless of how it was entered. Nothing wrong with your settings — the problem is in the code. A fix will land in the next release. * For user exclusion — since caching and CDN are off the table, we’d like to narrow it down. Could you check one setting for us: go to **SlimStat > Settings > General > Tracker** and let us know whether it’s set to “Server” or “Client (JavaScript)”? That’ll point us to exactly which code path is involved in your setup. Thanks again for your patience with this.Cheers * Thread Starter [tkbuhler](https://wordpress.org/support/users/tkbuhler/) * (@tkbuhler) * [1 month ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18855889) * It is currently set to Server. * Thank you. * Thread Starter [tkbuhler](https://wordpress.org/support/users/tkbuhler/) * (@tkbuhler) * [4 weeks, 1 day ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18858437) * To follow up (from my original post) on what i see as Bots being tracked on my site: * Even though many views on individual site pages, SlimStat shows 0 sessions today( typical recently), and also 0 Human Visits under Audience. There is a lot of activity under Pageviews, but why does this not correspond to hits under Human Visits (unless these are Bots or Crawlers)? * Also i have another statistics plugin that shows no corresponding hits, and basically zero overlap with what SlimStat shows me. Overall — the behavior of these “visitors” to my site doesn’t correspond with expected behavior on my site; the locations appear to be very random, international sources i also wouldn’t normally expect( also recently, many of them are hitting the robot.txt file at my site root).  * Plugin Contributor [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * (@parhumm) * [4 weeks, 1 day ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18858512) * Hi [@tkbuhler](https://wordpress.org/support/users/tkbuhler/) , * Thanks for this follow-up — it’s the detail that cracked it. * We found the root cause: it’s a bug in server-side tracking mode. When the tracker is set to “Server” (as yours is), session IDs aren’t being assigned to pageviews. Every record gets a session ID of zero. The “Human Visits” chart only counts visits with a valid session ID, which is why it shows 0 — even though the pageviews are real and being recorded. * This also explains why the traffic looks bot-like: without session IDs, every pageview appears as a standalone hit with no visitor continuity, which mimics crawler behavior. And it’s likely why your user exclusion appeared broken — without session context, it’s difficult to distinguish which pageviews belong to you vs. anonymous traffic. * We’ve filed this as a bug: [https://github.com/wp-slimstat/wp-slimstat/issues/257](https://github.com/wp-slimstat/wp-slimstat/issues/257) * **Workaround until the fix ships: **switch the tracker to **Client (JavaScript)** under **SlimStat > Settings > General > Tracker**. This mode assigns session IDs correctly and will give you accurate Human Visits and Sessions data right away. * For the **cpt:attachment** exclusion — that fix shipped in **v5.4.5. Please update** and it should work correctly now. * For user exclusion — once the server-mode fix lands (or after you switch to Client mode), could you check again whether your excluded user is still being tracked? With proper session IDs in place, we’ll be able to tell definitively whether there’s a separate issue there. * Thanks for sticking with this — your persistence uncovered a significant bug that affects all server-mode users. * Cheers * Thread Starter [tkbuhler](https://wordpress.org/support/users/tkbuhler/) * (@tkbuhler) * [3 weeks, 6 days ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18859876) * That all sounds great, thanks. So far with the recent update i have not had the problem with user being tracked. * Plugin Contributor [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * (@parhumm) * [3 weeks, 6 days ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18860370) * Hi [@tkbuhler](https://wordpress.org/support/users/tkbuhler/) , * Great to hear the user exclusion is working again — thanks for confirming. * **We just released v5.4.6**, and it addresses everything we worked through in this thread. 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. 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 running a caching plugin, 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 still looks off, we’re right here. * Cheers * Plugin Contributor [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * (@parhumm) * [2 weeks, 4 days ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18868497) * That’s great to hear, [@tkbuhler](https://wordpress.org/support/users/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. Viewing 11 replies - 1 through 11 (of 11 total) You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fproblems-with-recent-updates%2F%3Foutput_format%3Dmd&locale=en_US) to reply to this topic. * ![](https://ps.w.org/wp-slimstat/assets/icon.svg?rev=2832242) * [SlimStat Analytics](https://wordpress.org/plugins/wp-slimstat/) * [Frequently Asked Questions](https://wordpress.org/plugins/wp-slimstat/#faq) * [Support Threads](https://wordpress.org/support/plugin/wp-slimstat/) * [Active Topics](https://wordpress.org/support/plugin/wp-slimstat/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/wp-slimstat/unresolved/) * [Reviews](https://wordpress.org/support/plugin/wp-slimstat/reviews/) ## Tags * [slimstat](https://wordpress.org/support/topic-tag/slimstat/) * 11 replies * 2 participants * Last reply from: [Parhum Khoshbakht](https://wordpress.org/support/users/parhumm/) * Last activity: [2 weeks, 4 days ago](https://wordpress.org/support/topic/problems-with-recent-updates/#post-18868497) * Status: resolved