Plugin Support
Lap
(@lapzor)
Hi,
That is correct. Koko makes a tiny Ajax request to send the statistics to your server. This call can’t be cached because if it was served from cache that visit wouldn’t be counted. It should not use much resources though.
Hope that helps. If you have any questions, please let me know!
Thread Starter
roam92
(@roam92)
Thank you for your fast response, Lap!
You’re right, and I realized the call could not be cached… Does Koko make one single call for each visitor pageview then?
If so, then it sounds like there is not a way to tune this activity, or reduce the number of calls. I had wondered if I could trade off the frequency of stats updates for fewer Ajax requests, but perhaps that is not possible.
Plugin Support
Lap
(@lapzor)
That wouldn’t be possible, the Ajax call is not about updating the totals, it’s the actual counting of the visit itself. It does so on each page view.
If your uploads folder is writable it will try to do the initial counting completely outside of wordpress to save on overhead. If it detects it can’t write the needed file to your uploads folder (not writable or in a custom location) it will fall back to using the admin-ajax call that does need to load the wordpress overhead.
Hope that helps. If you have any questions, please let me know!
Thread Starter
roam92
(@roam92)
Ah! OK, this is very very helpful to know…
So what you’re saying is that the admin-ajax calls are a fallback, and that it may be possible to avoid them or reduce them? That is significant.
What can I do to make sure the first option is possible? Does/can Koko indicate to the user which technique it is using, or how to change it?
I checked my site’s /wp-content/uploads/ folder and there is a file called “pageviews.php” – is this the mechanism you are referring to?
It is a very small file (currently only 89 bytes), however it appears to be updated frequently and maintains a recent date/timestamp.
Thank you so much for your help and clarifications on this important functionality! I really appreciate it.
Plugin Support
Lap
(@lapzor)
They are a fallback to another Ajax call, that’s just not via the wordpress system, but there will always be a call to the Koko script to collect analytics one way or another on each pageload.
Koko will write statistics to that file temporarily and then collect them later in the background. Koko will automatically use the best/fastest way that is available on your setup.
Thread Starter
roam92
(@roam92)
I see, so does that mean that Koko is currently functioning as optimally as possible on my site?
In other words, is there anything further that I can do or verify for my setup to assure the best/fastest way for Koko’s operation?
I understand the plugin will “find” a way to work – I would just like to make sure that it is working as efficiently as it can.
The reason I ask is because my host seems to be indicating that the WordPress overhead is indeed being loaded on each Admin-AJAX call, which seems confusing based on what you said above.
Thank you again!
Plugin Support
Lap
(@lapzor)
No it is not because it is currently using admin-ajax.php instead of it’s own ajax endpoint.
You can try
define( ‘KOKO_ANALYTICS_USE_CUSTOM_ENDPOINT’, true); in you wp-config.php file to force the other method, do make sure your uploads folder is writable and in the default location.
Hope that helps. If you have any questions, please let me know!
Thread Starter
roam92
(@roam92)
Thank you @lapzor – so I put that line into my wp-config.php file, and my site’s hosting dashboard now shows a small fraction of the Admin-AJAX calls that it did before…
However, Koko also shows 0 visitors for today – meaning the analytics have stopped working/counting.
My uploads folder is in the default location, and we know that folder is writable is because there used to be a small file there called “pageviews.php” which Koko had updated frequently, but which is now gone entirely.
So, what’s gone wrong?
Thread Starter
roam92
(@roam92)
@lapzor and @dvankooten – help!
I’ve followed your suggestions above and added define('KOKO_ANALYTICS_USE_CUSTOM_ENDPOINT', true); to my wp-config.php file, and everything else seems in order…
The good news: According to my host’s dashboard, my site’s WordPress Admin-AJAX calls have dropped from ~20,000/day to ~200/day.
The bad news: Koko Analytics now shows my daily traffic at zero visitors. In other words, it no longer works and has stopped counting entirely.
Yet, Koko itself is still running – the plugin is definitely activated and I can see some of its calls in my site’s logs…
I’ve read over the discussion above several times and I still don’t fully understand it – could there be a bug in the plugin code somewhere?
(Running on an nginx hosting platform, if that helps.)
Thank you again!
Plugin Support
Lap
(@lapzor)
Well, that was to be expected as Koko would already automatically have chosen the best way, which in your setup seems to be using the WordPress Ajax call. I recommend just removing that line from your wp-config again. It means that for whatever reason Koko is not able to write the needed file without making the WordPress Ajax call.
Thread Starter
roam92
(@roam92)
Thanks, but what possible reason could that be?
The needed file you’re referring to /wp-content/uploads/pageviews.php, isn’t it? That is a very small file which was written to frequently before adding the define() statement you suggested above…
The uploads folder is writable and it’s in the default location, so I’m still trying to understand why Koko isn’t working like you said it should…
If the plugin doesn’t do or perform as you expect, wouldn’t that indicate a bug or other issue somewhere? Thanks again.
Hello @roam92,
First things first: Koko Analytics indeed performs an HTTP request to /wp-admin/admin-ajax.php for each and every pageview to store the information from that pageview in a file in your uploads directory. This is the default method (and it is working for you judging by the number of AJAX calls your webhost reported and the fact that you had working analytics before).
There is no way around this request, but there is a way to speed-up the resource cost for this request for most WordPress installations which use the default WP directory structure. If you are using a standard WordPress installation and your WordPress root directory is writable then Koko Analytics will switch to this optimized endpoint automatically, there is no need for you to do anything.
Now if you manually set define('KOKO_ANALYTICS_USE_CUSTOM_ENDPOINT', true); then you will force Koko Analytics to switch to this faster endpoint file, but most likely the faster endpoint file is either not installed in your root directory or it isn’t working because your directory structure is non-standard.
You can get around this by manually placing this file (name: koko-analytics-collect.php) in your WordPress root directory and making sure the path to your uploads directory is correct. I would only do this after first trying to have the plugin install it by default, by making your root directory writable (you can revert the permissions after the file is in place).
I hope that clarifies a little. If not, let us know please.
Thread Starter
roam92
(@roam92)
Thank you @dvankooten – that is very helpful and clarifies a great deal.
I see also that you updated the plugin this morning to add more information about what’s going on – I think that’s a good idea.
So I just upgraded to the new version 1.0.23 and indeed, the Settings page indicates: “❌ The plugin is currently not using an optimized tracking endpoint.”
I am still not sure why the plugin cannot create/link the koko-analytics-collect.php file on its own. My site’s directory structure is absolutely standard, and my WordPress root directory is indeed writable (755 permissions).
Running the WP Site Health tool shows:
Filesystem Permissions – Shows whether WordPress is able to write to the directories it needs access to.
The main WordPress directory: Writable
The wp-content directory: Writable
The uploads directory: Writable
The plugins directory: Writable
The themes directory: Writable
The must use plugins directory: Writable
Do you have any idea on why Koko can’t do the write itself, given all of the above? I am mystified.
So, I followed the instructions given in the Koko Settings screen and manually added the file koko-analytics-collect.php into the WP root with the contents specified… I cleared cache and now I get:
“✓ The plugin is currently using an optimized tracking endpoint. Great!”
I will report back on what happens after this runs for a while.
Thank you again!
Plugin Support
Lap
(@lapzor)
No idea why the plugin isn’t able to write the file by itself, there is too many possible hosting configurations for us to cover all of them. Glad to hear you got it to work by manually creating the file and thanks for helping us improve the plugin.
Thread Starter
roam92
(@roam92)
Thanks and glad to help. So, here’s the report I promised:
As posted above, when I previously added the define('KOKO_ANALYTICS_USE_CUSTOM_ENDPOINT', true); statement to my wp-config file, Koko had stopped counting entirely.
Then yesterday I manually added the koko-analytics-collect.php file to my WordPress root directory, and I cleared all site caches multiple times…
The good news: Koko started counting again immediately. Numbers started going up again.
The bad news: It is counting only intermittently, only a fraction of the pageviews. Somehow, it is missing ~80% of site visitors.
In other words, there appears to be some sort of problem with properly counting most visitors using the Koko custom endpoint. And it’s not a caching issue.
I checked the my WP uploads directory and the pageviews.php file is once again being repeatedly created, updated, and removed there, as before.
However, it is definitely not being changed for every new pageview that’s happening on the site… Should it be?
Thanks.
