if (c::get('stats.session', false)) {
s::start();
// Get the already visited pages
$urls = s::get('stats', array());
// User has visited this page already in this session. Do nothing.
if (in_array($param, $urls)) {
return;
}
// User has never been here. Add the url and put back in the session storage
$urls[] = $param;
s::set('stats', $urls);
}
It seems to be a bug. I’ve already issued it at GitHub.
As a workaround I deleted the stats.php from the plugins folder and added this line of code to my footer snippet.
@criuz: I wanted to use the router for the plugin in order to enable it for all pages without having to edit any of the templates or snippets. This means you can either use custom routes or kirbystats at the moment.
As a workaround @tobiasfabian’s solution should work. I’ll have to look at the router in more detail and see if I can find a nice and easy way to solve this.
The stats are saved in a page called kirbystats. In the frontend, you can access the data, but you have to create your own graph, if you need anything like that. To get the data:
// inside any kirby code, probably a snippet
$kirbystats = page('kirbystats');
$hits_per_page = $kirbystats->pages()->yaml();
$hits_per_date = $kirbystats->dates()->yaml();
```
```$hits_per_page``` then contains an associative array of pages and their total hit count, `$hits_per_date` the hits per data recorded by the plugin, independent of the page.
Cool, thanks. I basically just need to sort by hits, and pull the top pages, and filter by whether they’re part of the blog. Once I get that data from the kirbystats page, I should be able to do all that.
Hi … I’m using the plug-in on my site but it only counts hits on the home page but not on any other (sub)page. The site has two languages … any ideas, what I did wrong or how I can investigate this further …?
I should really add a note to the github repo that this was just an experiment and is not intended for production use.
Alternatively, maybe I can find a way to replace the update function with some hacky toolkit code to prevent the cache flush. I’m not sure whether I like that though… Have to take a closer look at the core to see how I can work around that.
Because the cache invalidation works the other way around. The cache needs to be flushed because other pages might need to be updated with the changed content, for example in navigations or a blog overview etc.