Hi, I’ve noticed another issue since the last update: page tracking is blocked. All views returned to 0, then after clearing the cache, they returned to their pre-update values. Since then, the view counter has stopped moving, despite visits to pages and articles. Thank you for your help.
Hi @rogierlankhorst After disabling and re-enabling Burst, the page tracking issue is still there. I think the update went wrong, some of my sites are working properly and some are not (all my sites are running with the same theme, plugins, and configuration). I really don’t understand what happened, the Site Health Burst log doesn’t indicate any anomalies.
This reply was modified 2 months, 1 week ago by kromaweb.
@kromaweb sorry for my late response, I missed your last post.
Can you check also if the latest rows in the burst_statistics table also have a page_id and page_type? Because if they do, it almost looks like there is some persistent database caching at work.
– page_id and page_type seem to be updated.
– counts on the pages and posts overview and in top bar are result of direct queries on the burst_statistics table.
So there is no obvious explanation to this. It is hard to debug this over the forum. If you want you can contact me directly at support(at)burst-statistics.com so we can dive deeper into this.
@rogierlankhorst All rows in the burst_statistics table have a page_id and a page_type.
I uninstalled the plugin on another site (it had the same problem) by deactivating and deleting all the data. The counter returned to 0, then started displaying visits correctly. I don’t know if this might be a clue to fix this without having to delete the data.
@rogierlankhorst I found the source of the problem by deleting the data and reinstalling Burst on my site. My theme allows you to use a page to create a footer, which is what I did for my site. Since the footer is a page, Burst assigns it a page_id and a page_type. My footer is incremented across all pages and posts on my site; Burst doesn’t understand this, and all the statistics are displayed on my footer page. When I deactivate my footer page, the statistics work again.
I’ve attached screenshots to illustrate my point.
If there’s no way to fix this problem, I’ll have to switch tools quickly.
@kromaweb This is very helpful info. So the issue is that the data-burst_id attribute in the <body gets the footer page_id instead of the actual page_id. I have made a change that possibly resolves this in the same branch:
@kromaweb in the last update several changes are implemented that should resolve the issue:
– page_id detection improved to resolve the wrong page_id you encountered
– limit page count to last 30 days for performance
– offer screen option to switch to other time ranges
– extended default page count display to all public post types.
I hope this resolves the issues you were experiencing.
@rogierlankhorst The update removed old page traffic tracking, even on sites where there were no issues. Limiting page counts to 30 days is a step backward from previous versions. I understand the performance argument, but why not give users a choice? A new issue appeared with this update: when a page exceeds 1,000 visits, the counter on the front panel displays 1.
