Please set JS MODE to no in the options, and see if that helps.
A vote for my plugin would be a nice way to say thank you.
Ahh, if Javascript mode was enabled by default during an update maybe that’s why my JS mode was enabled & hits dropped off too? Perhaps during updates it can check for which setting the user had set previously (if it doesn’t already) and make sure the same setting persists, for continuity (no sudden, unexpected “bathtubs” in graphs due to JS-mode / non-JS-mode flip flop)?
I’m wondering if it shouldn’t just capture ALL hits and the JS-mode simply changes the DISPLAY rather than affecting “data collection” (or give the option of whether to make a “hard change” or “soft change”, IE change “data collection” vs. changing “data display”), to avoid the “bathtub effect.”
That is, if it’s a “hard change” it creates a “bathtub” in the data where there is seemingly a literal LOSS of data collection over that period (disabling JS mode doesn’t “add back in” hits lost due to non-collection). It doesn’t mean the hits weren’t there, it just means they weren’t collected, thus overall counts/records are affected. Seems to me like changing the mode shouldn’t per se affect “collection” so much as playback. Unless for some reason there is a specific need to use less database space, etc.
It was enabled by default because that option didn’t exist before, and most users suggested to have it enabled by default, which is the most common setting.
If WP SlimStat captures ALL hits (which is pretty much what it was doing before), then there’s no reliable way to tell who is human and what is a bot, because the latter sometimes disguises itself as human. The only reliable way to tell is by asking it to execute some Javascript, which 98 times out of 100 it won’t execute, because that’s how bots work 😉
Plus I don’t see the point of keeping all the extra junk in the database, if you are not going to use it anyway.
Case closed.
Camu
