Parhum Khoshbakht

Hi @guenther999 ,

Just checking in — since v5.4.2 has been out for a while now and we’ve continued improving things, we’d recommend updating to the latest version v5.4.4, which includes additional stability and performance improvements on top of the fixes mentioned above.

You can update directly from your WordPress dashboard under Dashboard → Updates.

Feel free to open a new thread if anything else comes up.

Best regards,
The SlimStat Team

Hi @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

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

Hi @kelogs

Thanks for reporting this, kelogs. A site going unresponsive with 503 errors is serious and we appreciate you narrowing it down to the plugin.

You hit a known performance bug in v5.4.1 where the visit ID generation could overwhelm the database under normal traffic, exhausting PHP workers and causing exactly the 503 pattern you described. We identified the root cause and shipped a fix in v5.4.2.

Please re-enable the plugin and update to v5.4.2 through your WordPress dashboard (Plugins > Updates). That should resolve the 503 errors completely.

Let us know how it goes after the update.

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

Hi @dxylott54 ,

Good news — v5.4.2 is now available, so you can skip 5.3.5 entirely and update straight to 5.4.2 through your WordPress dashboard. It includes all the security fixes from 5.3.6, 5.4.0, and 5.4.1, plus a number of bug fixes and performance improvements.

Since you’re coming from 5.3.5, this single update will get you fully caught up. We’d recommend updating at your earliest convenience given the security patches included.

Thanks for your patience

Hi @enjoybeerlife ,

Just a quick follow-up — version 5.4.2 is now available and includes the fix for the early translation loading notice. The textdomain now loads at the correct hook as WordPress 6.7+ requires.

Please update through your WordPress dashboard and the notice should be gone across all your sites.

Thanks again for reporting it!

Hi @toxicum,

Quick update — this bug is now fixed in version 5.4.2, which is available now. The crash during background geolocation database updates has been resolved, along with several other geolocation improvements.

Please update through your WordPress dashboard and the cron error should be gone. And yes, you were right that the other geolocation threads were likely related — v5.4.2 addresses those as well.

Thanks again for the detailed report and for connecting the dots on the related threads!

Hi @senribb ,

Glad to hear the shortcodes are working again!

The geolocation provider issue you’re seeing has been fixed in version 5.4.2, which we just released. We rewrote how the geolocation settings are handled — the provider selection now saves and applies correctly, and the database downloads are much more reliable.

Please update to v5.4.2 through your WordPress dashboard (Dashboard > Updates), then go to SlimStat > Settings > Tracker, select your preferred geolocation provider, enter your MaxMind license key, and save. The setting should stick and the database will download automatically.

Let us know if everything works as expected after the update!

Hi @enjoybeerlife ,

Thanks for reporting this — you’re right that the translation loading timing wasn’t aligned with the WordPress 6.7.0+ requirement.

We’ve already fixed this in our upcoming v5.4.2 release. The textdomain now loads at the init hook instead of earlier, which is exactly what WordPress expects. The release is coming very soon, so you should see the notice disappear once you update.

In the meantime, the notice is harmless — it doesn’t affect tracking or any plugin functionality. You can safely ignore it until the update lands.

Best,
The SlimStat Team