Compatibility issue with wp fastest cache

Hi Birbo

Also experienced some issues with Fastest Cache and Slimstat.

Try creating an Exclude JS rule in Fastest Cache – add a new rule, that excludes JS url’s that include “wp-slimstat” (without the quotes) – see if that helps.

Maybe/maybe not related, it can be wise to schedule a “Cache Timeout” no later than every 8 hours. Fastest Cache can interfere with Forms and Nonces.

Give it a try and please share your findings.

Sadly I can confirm too that slimstat is NOT compatible with WP Fastest Cache as of today. I excluded everything slimstat JS, tried excluding cookies, changing settings in slimstat, disabling minify in WP Fastest Cache, every combination. I’ve used WordPress for almost 15 years. There is a problem using slimstat and WP fastest cache. Doesn’t matter if Slimstat is set to client or server, excluding JS files in WPFC, or any configuration with or without Cloudflare.

Slimstat is broken with WPFC ??

Hope this gets fixed soon. Hope your recovery is going good!

Also, for what it’s worth. The minute I disable WP fastest cache, Slimstat instantly shows ALL traffic as normal. So it’s obviously something wrong ??

One last thing to help.
I know for a fact that the wp-slimstat.min.js is loading on the pages, GTX and other traffic tests show the javascript loading fine. The traffic report simply won’t show the visits in Slimstat traffic page in real time or even historically. They are just ignored. All visits are ignored. ONLY 404 errors to non-existent pages show in traffic page. (i.e. “static” pages are ALL ignored once cached, only “new” pages show up in Slimstat traffic log – thus, the pages with names that don’t exist.)

It doesn’t matter what minify or javascript settings you disable in WP fastest cache, slimstat simply does not work with this cache plugin anymore.
Sorry.

Hope it can be fixed.

• This reply was modified 5 years, 8 months ago by thescarletfire.

Yes, unfortunately we’ve tested WP Fastest Cache, and there’s no way around the issue. Maybe the developer behind that plugin could provide ways of detecting the cache for us? Has anyone tried to reach out to them?

Sorry,
Jason

Hmm not really resolved but ok. ??

Hopefully you’re able to address this in a future soon update of SlimStat. Other
cache plugins have the same issue with SlimStat, not just fastest cache. It just happens to be among the most popular plugs.

Please know that it’s SilmStat that has the issue. It is unable to work correctly with “static” cached pages.

And pretty much 99% of websites out there now coded by a competent admin, they all cache using static pages.

So, that means Slimstat only works on a SMALL selection of websites out there- only those who don’t cache their own site and thus, “slow” websites can only use SlimStat. And in 2019 who doesn’t cache their website in WordPress?

I suggest you look into this if you want Slimstat to be used more by other websites. All cached websites cannot use Slim. W3 does not work, fastest cache does not work, despite any claims of W3.

Good luck! Glad to have you back ??

Hi @thescarletfire,

I’m sorry but I must disagree with your statements here above.

Slimstat is designed to work with static pages without any issues, as long as the tracking code can be attached to those pages. We have tested our plugin with many caching plugins, and they all seem to play nice with the tracker, except WP Fastest Cache. Please show me what other plugins create issues, with an actual example of a non-working website, so that we can try and replicate the issue on our end.

Slimstat is currently used on thousands of “cached” website (including our own) without any issues.

Again, the issue with Fastest Cache is that for some reason it removes the tracking script from the source code. Unlike other plugins, it looks like the exceptions you can define in the settings don’t work as expected. My recommendation is that you reach out to the developer behind that plugin to see why those exception are not working as expected.

Best,
Jason.

Thank you for clearing that up. I guess that’s too bad for the cache plugin.
I wouldn’t know where to start to “put back” the tracking code they remove.
Does the dev of a cache plugin know how to do this I wonder?

Sure i will open a new thread and show you a properly installed and tweaked W3 install does *not* work with Slimstat current version. Only static “404” errors for pages that don’t exist (thus, never before visited) are recorded in live traffic. Zero traffic otherwise is reported in Slim. I’ll make a little mp4 screencast showing you. I’ve loved Slim for YEARS, so believe me, I want nothing more than to keep using it!

Pinky swear :))

• This reply was modified 5 years, 7 months ago by thescarletfire.

@thescarletfire could you set it up so that I can get a temporary account to look at the backend and run some tests on your environment?

Believe me, I know you have the best intentions, and I do appreciate this kind of constructive criticism: that’s what makes this plugin so good! Users telling us how to make it better every day. It’s just that general statements like “Slimstat only works on a SMALL selection of websites out there” are not accurate and portray a false representation of all the hard work we’ve put in our plugin! I hope you understand.

In the meanwhile, I’m going to setup a new fresh install of Slimstat and WP Fastest Cache in our dev environment, and play with it a little.

Best,
Jason.

Absolutely right. I’m sorry. Sometimes my brain and my language fail to work together. Thanks for setting up a dev environment for a little testing. We appreciate all you do.

So, after playing with the new version of WP Fastest Cache, it does look like they must have addressed the exclusion list. The following settings work with Slimstat:

https://pasteboard.co/IbDETw9.png

My page views were tracked without any issues, having Slimstat set as “Client Side” tracker.

Please let me know if those settings work for you.

Best,
Jason

Hi Jason.

just FYI your settings don’t actually show it correctly. You would need to preload the cache and produce static HTML files in order to see that indeed, it’s not tracking at all.

I would not be surprised if the free version of WP Fastest Cache and no preload together works with SlimStat. As that’s not a very powerful cache setup, compared to a full preload and full minify options enabled. Sorry! But we users appreciate all your support ??

I *would* be surprised if you preload your cache, check the timestamp in a HTML page to confirm the static HTML (in your FTP or directory *.html etc), and THEN slimstat tracked those pages ?? hehe

All the pages in my dev setup have the WPFF signature, which looks like:

<!– WP Fastest Cache file was created in 0.27939105033875 seconds, on 24-04-19 16:15:22 –>

So they are being cached, unless I’m missing something? I also checked the filesystem, and I do indeed see a bunch of HTML files and folders under

/wp-content/cache/all/

Anyway, I enabled the “preload” feature in the free version, and Slimstat is still working. If you’re using the premium/paid version, would you mind giving me access to a temporary clone of your website to try and troubleshoot the issue directly where it happens, since I can’t reproduce it on my end?

Best,
Jason

Interesting! Hmm, that does sound static HTML cached yes. I could setup a quick temp login for you later on sure. No problem.

I used to use SlimStat on server vs. client for a long time, because I prefer to be as close to my apache logs as possible seeing everything, bloat and all. But do you think I’d be forced to switch to client in order for this all to work correctly with the cache?

Will email you the dev setup.