Koko doesn’t seem to recognize optimized endpoint file
-
Hi, using latest version of Koko and it tells me “The plugin is currently not using an optimized tracking endpoint.”
The plugin cannot seem to create the file itself, so I copied the suggested contents to
koko-analytics-collect.phpand uploaded it to my WordPress root directory, making sure it has the right permissions (the file is 644, with root directory permissions of 755).However, Koko apparently does not recognize that the file is there and is still giving me the same message above.
I tried clearing all page caches, etc. Running on a Kinsta server with Cloudflare APO.
The good news is Koko seems to be counting visitors/pageviews and the buffer file is moving along, but how do I get the optimized endpoint to work? Thanks!
-
Hi @roam92,
What happens if you use the button on the settings page for creating the optimized endpoint file? Do you see an error message of any kind? And if you use the button after manually creating the file with the suggest file contents?
Hey Danny, thanks for your response. If I use the button with no file there, then I get the message: “Unable to install optimized endpoint. Please create the file manually and then try again.”
If I manually create/add the endpoint file in the WP root dir and then try the button again, same message.
In both cases, Koko’s Settings page tells me: “The plugin is currently not using an optimized tracking endpoint.”
Thank you for this product!
Oh, one other thing I definitely should mention:
When trying the Create button on the Settings page after I’ve manually uploaded the endpoint file, Koko gives that same “unable to install” message – however, oddly, the manually-created endpoint file disappears off the server! Meaning, the file is gone after pressing that button.
I’ve just tested this several times and the same thing happens each time.
Hi @roam92,
The file being removes is caused by the plugin attempting to clean-up after itself, not knowing that it was you who put the file in place. It works by first trying to create the file if it doesn’t exist there already and then issuing a dummy request to the endpoint to see if it works. If it doesn’t work, it removes the file again and instructs the rest of the plugin to not start using that endpoint.
So in your case, it looks like somehow the plugin is failing to verify the file to see whether it works.
We can see what exactly is going wrong by you manually creating the file and then visiting it in your browser by going to the following URL on your site: /koko-analytics-collect.php?nv=1&p=0&up=1&test=1
The plugin doesn’t return any meaningful content (to preserve bandwidth), but the HTTP headers should tell us whether the file is working as intended. Could you please manually create the file and then place a link to your site here so that I can take a look?
Best,
DannySure, below are the response headers from hitting that URL.
What’s strange to me is that the plug-in clearly has the capabilities to remove the endpoint file – but seemingly not to create or see it. Does that sound right to you?
Thanks again.
—————–
Response Header:
HTTP/1.1 200 OK
Cache-Control: no-cache, must-revalidate, max-age=0
Connection: close
Date: Mon, 12 May 2025 19:09:10 GMT
Server: cloudflare
Vary: Accept-Encoding
Content-Type: text/plain;charset=UTF-8
Alt-Svc: h3=":443"; ma=86400
Cf-Apo-Via: origin,qs
CF-Cache-Status: BYPASS
CF-Ray: 93ec35785d967c6b-LAX
Expect-Ct: max-age=86400, enforce
Ki-Cache-Type: None
Ki-CF-Cache-Status: BYPASS
Ki-Edge: v=21.0.0;mv=4.1.4
Ki-Edge-O2o: yes
NEL: {"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}
Referrer-Policy: same-origin
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=NsxwRCchr5v%2BqMV7mXwta2pC47WN7EnsmrXumFCBrXTwbfg8cUaF873ChbWQo3UJEyQNRjVKsQjzIXvURPP6Zm5grs%2FcTN0Sfo7MxFe%2Fnycfcio7YgjfceIJO30O9ClKHQW9Jw%3D%3D"}],"group":"cf-nel","max_age":604800}
Server-Timing: cfL4;desc="?proto=TCP&rtt=520&min_rtt=514&rtt_var=205&sent=6&recv=6&lost=0&retrans=0&sent_bytes=3134&recv_bytes=900&delivery_rate=7688495&cwnd=252&unsent_bytes=0&cid=0589acd5075746c7&ts=479&x=0"
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
Tk: N
X-Content-Type-Options: nosniff
X-Edge-Location-Klb: 1
X-Frame-Options: SAMEORIGIN
X-Kinsta-Cache: BYPASS
X-Xss-Protection: 1; mode=blockThank you @roam92 – I just pushed an update this morning in which the plugin will only remove the file if it actually just created it. That will help us rule out any permission issues.
What’s weird is that those HTTP headers look correct to me, yet somehow the plugin still thinks it doesn’t work.
You can manually enable the use of the optimized endpoint by taking the following steps:
- Ensure that /koko-analytics-collect.php exists with the contents suggested by the plugin.
- Go to /wp-admin/options.php on your WordPress site.
- Locate the “koko_analytics_use_custom_endpoint” option.
- Change the value to “1” (without the quotes).
That should enable the optimized endpoint. I’m not entirely sure why it doesn’t automatically work on your site but I’ll do some more digging and hope to discover the root cause.
Best,
DannyThanks, Danny. I removed the manually-added endpoint file, updated the plugin, and then tested again.
Koko still can’t create the file itself from the Settings page, nor apparently can it “see” the file if I add it manually – but at least it has stopped removing the file if I hit the “Create” button again.
So I just made the change to options.php that you suggested, and now Koko’s Settings page says: “The plugin is currently using an optimized tracking endpoint. Great!”
The stats still seem to be increasing as normal, so that’s good. But how can the plugin use the endpoint file if it can’t actually see/recognize it on the Settings page?
Is there any way to be sure that it’s actually doing it, and confirm that it’s running properly with the optimized endpoint?
Thanks again.
You can check whether the plugin is really using the optimized endpoint by opening up any page on your site and checking your browser’s Developer Tools’ Network tab. There should be a request to the file named /koko-analytics-collect.php instead of a request to /wp-admin/admin-ajax.php?action=koko_analytics_collect.
The plugin determines which endpoint to use by checking whether the koko-analytics-collect.php file exists and when the koko_analytics_use_custom_endpoint option is enabled.
Thanks for the guidance. I did that and unfortunately, it is still definitely requesting /wp-admin/admin-ajax.php?action=koko_analytics_collect. Confirmed with multiple pages and on different browsers.
Meaning, it’s not using the optimized endpoint – despite setting the option to tell it to do so.
I suspect that means the plugin still can’t see the uploaded file, since you said there is an “and” condition happening there?
In other words, Koko still doesn’t believe the file exists. How could that be?
The whole thing is just really strange. I am still trying to figure out how it was able to delete the endpoint file (before the recent update), yet still not be able to create or see it.
Hello @roam92,
Can you please confirm that the plugin states on its settings page that it is using the optimized endpoint while requesting the /wp-admin/admin-ajax.php?action=koko_analytics_collect endpoint at the same time? The logic for the two showing the message on the settings page is the same as for determining what endpoint to use, so this should definitely not be occurring. Unless you’re viewing some kind of cached page.
One thing I forgot about in proposing this workaround is that the plugin is periodically (every hour) testing whether the optimized endpoint still works. This is a defense mechanism against people moving around their website or using a non-standard WordPress directory structure. If the plugin fails to detect a working optimized endpoint, it will revert to the default one.
I’ll see if I can add more detailed error messages to the button that attempts to create and verify the optimized endpoint file so that we can more easily see what step exactly is failing.
Best,
DannyThanks. So, very strange… The “1” setting in /wp-admin/options.php had been cleared. I didn’t do it.
I set it to “1” again and did some more testing. The first new page I hit after changing the option did actually show the optimized endpoint being used (/koko-analytics-collect.php).
However, the option was somehow immediately cleared again and set back to blank… And options.php confirmed this. Koko then returned to using admin-ajax for everything – and not the optimized endpoint.
So no matter what I do, I am stuck at “The plugin is currently not using an optimized tracking endpoint” because it always reverts, and doesn’t see the endpoint file that I manually uploaded.
I hope you can figure this out, because I sure can’t!
The site is using Kinsta and FlyingPress with Cloudflare APO caching.
Agree that more details or info (like a debug option or readout) might be helpful.
Hello @roam92,
Can you please try updating the Koko Analytics plugin to the version from this ZIP package (it’s the latest development build): https://dannyvankooten-3.stack.storage/s/1MI9IsvAnen5Jc0V
It includes a specific error message after hitting the “create optimized endpoint” button on the setings page to see what is going wrong exactly, or at least with some more detail.
What’s weird is that I just tested the latest release version of Koko Analytics on a fresh Kinsta environment and the optimized endpoint worked right away, without any manual action required. So something in your environment is causing this to happen; hopefully the more detailed error message will be able to point us in the right direction.Thanks. I removed the manually-uploaded endpoint file and updated Koko to your development build.
Pressing the “Create” button gives the message: “Unable to install optimized endpoint: Endpoint did not return the expected response”, and no file is created.
I then re-uploaded your suggested endpoint file but Koko still says: “The plugin is currently not using an optimized tracking endpoint.”
Hope that helps?
Hi @roam92.
Thank you – that definitely helps! It confirms my suspicion that the plugin is unable to verify that the endpoint is working. Which is strange, because if we request the endpoint ourselves in your browser then it does return the expected HTTP response.
Unfortunately the error message is still not telling us what parts of the response did not match, so I have prepared another version of the plugin that will write the received HTTP response to your PHP error log.Can you please try overwriting/updating the plugin to the version from this link: https://dannyvankooten-3.stack.storage/s/eO5mdcbLacZ9Z4gv
After installing that version, use the “create optimized endpoint file” button on the settings page once more. After doing that, there should be a new item in your PHP error log telling us exactly what HTTP response the endpoint file returned. That should give us a hint as to what exactly is causing this verification step to fail…Thank you for working with me here btw, I realise this must be quite the hassle but it’s a really weird issue that I unfortunately am not able to replicate myself.
Best,
DannySure, here’s the entry in the site’s error log:
2025/05/20 15:01:52 [error] 62559#62559: *850332 FastCGI sent in stderr: "PHP message: Koko Analaytics: Error verifying optimized endpoint because it did not return the expected HTTP response.
HTTP code: 403
HTTP headers: \WpOrg\Requests\Utility\CaseInsensitiveDictionary::__set_state(array(
'data' =>
array (
'date' => 'Tue, 20 May 2025 15:01:52 GMT',
'content-type' => 'text/html; charset=UTF-8',
'accept-ch' => 'Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA',
'cf-mitigated' => 'challenge',
'critical-ch' => 'Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA',
'cross-origin-embedder-policy' =" while reading response header from upstream, client: XXX.XXX.XXX.XXX, server: mysite.com, request: "POST /wp-admin/index.php?page=koko-analytics&tab=settings HTTP/2.0", upstream: "fastcgi://unix:/var/run/php8.2-fpm-kinstasitename.sock:", host: "mysite.com:59226", referrer: "https://mysite.com/wp-admin/index.php?page=koko-analytics&tab=settings"
You must be logged in to reply to this topic.
