Parhum Khoshbakht

Hi @dxylott54 ,

Thank you for the very clear report — and especially for the two videos and the screenshot. They made it easy for us to see exactly what is happening. Your English was very clear, no need to apologize.

You are right: both are real bugs in 5.4.11. We confirmed both by reading the code and reproducing the behavior against your WordPress version.

Issue 1 — Search box does not search what you type.
Tracked here: https://github.com/wp-slimstat/wp-slimstat/issues/298
The free-text input was replaced with a dropdown in 5.4.0. When the value you type is not in the dropdown list, pressing Enter does nothing. Work on the fix has already started. Typing a value and pressing Enter will apply the filter again, like it did in 5.3.5.

Issue 2 — Google Discover referrer is not recorded.
We opened a new ticket for this one based on your report: https://github.com/wp-slimstat/wp-slimstat/issues/306
Since version 5.4.0, the tracker passes the referrer through a WordPress function that silently drops any URL starting with android-app://. That is why com.google.android.googlequicksearchbox is empty in 5.4.11. We will allow android-app:// (and ios-app://) so Discover traffic shows up again.

Please do not downgrade to 5.3.5. The current 5.4.12 release fixes two security issues that 5.3.5 still has — a stored XSS and a SQL injection. Going back would put your site at risk. The two bugs you reported are real problems for analytics work, but they do not put your site at risk. The security holes in 5.3.5 do.

Both fixes are planned for the next patch release. We will not give you a fixed date, but they are at the top of our list. Thanks again — your report is exactly the kind of feedback that makes the next release better.

— The SlimStat team

Hi @adsim ,

Apologies for the late reply on this one – it should not have taken us this long to get back to you, especially when a stuck cookie banner blocks both your visitors and your consent flow in the meantime. Let’s get it sorted now.

Thanks for including the exact error message: that’s the single most useful detail you could have given us, and it lets us go straight to the right question.

The first thing we need to know is which SlimStat version is installed on this site (WordPress admin -> Plugins). The reason we ask first: this exact “SlimStat is not defined” on Accept was a known SlimStat bug in the 5.3.x line, fixed in version 5.4.0 by exposing the SlimStat object to the page properly. If you’re still on 5.3.x, updating SlimStat in place from the Plugins screen (your settings stay intact) should fix it on the spot. If you’re already on 5.4.x or later, the error has to be coming from another script on the page rather than SlimStat itself, because our banner’s Accept button doesn’t call anything named “SlimStat” directly – it’s wired up internally inside the same file that defines it.

In that case, the fastest way to find the script that is calling it is in your browser:

1. Open the page where the banner is broken.
2. Open the browser DevTools (press F12 on Windows or Linux, or Cmd + Option + I on Mac), then click the Console tab.
3. Click the cookie banner’s Accept button so the red error appears.
4. Expand the error and click the small file and line link on the right side. It will look like “cookieyes.js (line 412)” or “snippet-3.js (line 88)” – your filename will be different.
5. Copy that filename and line number into your reply.

Along with the version and that filename plus line, two more short answers would help us pinpoint it in one round trip:

1. Which cookie banner is on the site? (The SlimStat built-in banner, or another such as CookieYes, Real Cookie Banner, Complianz, Cookiebot, GDPR Cookie Consent, or something else.)
2. Does the same error happen in a private or incognito browser window while logged out? That tells us instantly whether the SlimStat tracker file is missing for everyone or only when you view the page logged in.

Send those back and we’ll take it from there.

Cheers, The SlimStat team

Hi @blackbird69 ,

Thanks for flagging this — that dropdown’s search field isn’t as obvious as it should be, and you’re not the first to miss it.

Typing an IP still works, it just moved one layer in. Click the “Select value” box to open it, and a search field appears at the top of the list. Type any part of an IP (e.g. “149.102”) and the list filters as you type — then hit Apply.

Quick shortcut: if the IP you want is already on screen, click the IP address shown next to a visitor in the Access Log and it applies as a filter instantly.

If the search field doesn’t appear when you open the dropdown, could you share your browser name and version, and – if you’re comfortable – open your browser’s developer console (F12 → Console tab) and let us know if any red JS errors show up when you open the filter? That’ll help us narrow it down fast.

Glad to hear it, @blackbird69 ! Thanks for coming back to confirm. Follow-ups like yours really help other folks searching for the same fix.

Hi @blackbird69 ,

Thanks for reaching out — that’s a great observation!

You’re not overlooking anything. There’s currently no setting to auto-expand panels on the Realtime page. When you hide the other reports and keep only the Access Log, it retains its default fixed height, which is why you see all that empty space below.

How to fix it with CSS — SlimStat has a built-in Custom CSS field:
1. Go to Slimstat > Settings > Reports tab
2. Scroll down to the Miscellaneous section
3. Paste this into the Custom CSS field:
.wrap-slimstat .postbox.tall .inside { height: 85vh; }
4. Click Save

Adjust 85vh to whatever suits your display — 85vh means roughly 85% of the browser window height.

That said, this is a legitimate improvement we should make — the plugin should detect when a single panel is visible and expand it to use the available space. I’ve logged this as a feature request: #295.

Thanks for the suggestion — it’ll benefit everyone who customizes their layout!

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 ww.wp.xz.cn (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!