Forum Replies Created

Viewing 15 replies - 1 through 15 (of 221 total)
  • Thread Starter roam92

    (@roam92)

    Hi Danny,

    Thanks so much for your reply and for the reference back to our previous conversation.

    1. So, my site is definitely able to run a PHP file in my WordPress root directory. I did a simple phpversion.php to double-check. It’s no problem.
    2. Regarding installing the endpoint, the /koko-analytics-collect.php file is still there (and has always been there). When I tell Koko to recreate it now, I get back the message: “Error verifying HTTP response. Unexpected response headers.” Nevertheless, Koko is able to recreate the file with the current timestamp.
    3. Back in June, I tried adding define('KOKO_ANALYTICS_CUSTOM_ENDPOINT', '/koko-analytics-collect.php'); to my wp-config.php file, and it didn’t do anything, so I took it out. The only solution I had found was to use the 1.7.5-dev version you provided. That version of Koko was able to successfully use the optimized endpoint. It was only when I upgraded to version 2 that the plugin lost that ability. Meaning, for some reason, Koko was able to automatically see the file in 1.7.5-dev, but not since.

    HOWEVER, the good news is that adding the define('KOKO_ANALYTICS_CUSTOM_ENDPOINT', '/koko-analytics-collect.php'); to my wp-config.php now WORKS!

    After adding that line back, Koko says “The plugin is currently using an optimized tracking endpoint. Great!” …and virtually all my site’s Ajax calls disappear, while tracking still works fine. I confirmed in the browser devtools that /koko-analytics-collect.php is being called on each pageload.

    So, something happened between version 1.7.5-dev and version 2.1.0 that makes it work now with the define() in place, but not without it… It still would be good to know why that is required and why Koko can’t figure it out on its own, as it was able to do in 1.7.5-dev.

    Thank you!

    Thread Starter roam92

    (@roam92)

    Hi Danny, thanks so much for your fast response. The impact on my site is not inconsequential. With many thousands of Ajax requests (from Koko now) instead of very few, hundreds more visitors hit the PHP Thread Limit and get queuing and timeouts. I don’t have a weak or cheap hosting plan with Kinsta/Cloudflare, either.

    Prior to upgrading to Koko v.2, I was using the 1.7.5-dev version you provided in the spring. That version was able to successfully employ the optimized endpoint and my Ajax requests were 2-3% of what they are now, with almost no visitors hitting the PHP Thread Limit.

    I had hoped that with six months passing, version 2 would be able to do the same. Are you saying that’s not possible, and that better performance can only be achieved if I downgrade back to 1.7.5-dev (which was able to see & use the endpoint file) and then stay on version 1 forever?

    Thank you again! Also for creating Koko. Really appreciate it.

    Thread Starter roam92

    (@roam92)

    Circling back to this. I’ve been using the 1.7.5-dev version you shared above for six months, as it has allowed my site to use an optimized endpoint and keeps the Ajax calls way down.

    But yesterday I finally upgraded to version 2.0.20, as the releases have slowed and the version looks more stable.

    After upgrading, under Settings, I saw:

    “The plugin is currently not using an optimized tracking endpoint.”

    …even though the endpoint file was still there. So I clicked the “Create optimized endpoint file” button again.

    The plugin then re-created koko-analytics-collect.php, still in the right directory and with the right permissions, but cannot seem to recognize it. The Settings page returned (at the top):

    “Error verifying HTTP response. Unexpected response headers.”

    …and continues to say, “The plugin is currently not using an optimized tracking endpoint.”

    When I test any webpage, I see that they only use: /wp-admin/admin-ajax.php?action=koko_analytics_collect …and the Ajax calls on my site are again very high.

    If I visit this URL on my site: /koko-analytics-collect.php?nv=1&p=0&up=1&test=1 …then I get:

    “This page isn’t working. HTTP Error code: 400 Bad Request”

    Yet the koko-analytics-collect.php file is definitely in the correct place and continues to remain there, with the right contents. And Koko is able to recreate that file anytime.

    I tested other .php files in the same root directory and they have no problem running.

    Looking at my site’s error log, I see the message included below.

    What can I do?? Thank you!

    2025/11/17 15:35:56 [error] 58666#58666: *757865 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' => 'Mon, 17 Nov 2025 15:35:56 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: 2600:4040:a03b:8a00:500e:d975:dd9a:ecaa, server: …, request: "POST /wp-admin/index.php?page=koko-analytics&tab=settings HTTP/2.0", upstream: "fastcgi://unix:/var/run/php8.4-fpm-….sock:", host: "…:59226", referrer: "https://…/wp-admin/index.php?page=koko-analytics&tab=settings"

    Thread Starter roam92

    (@roam92)

    “It could very well be that the optimized endpoint is actually not working on your site all together so the plugin is right in refusing to use it…”

    Danny, that’s not the case. It’s 100% clear that the plugin is correctly using the optimized endpoint in the 1.7.5-dev version you shared above.

    This is confirmed by the site’s AJAX Usage dropping off to a tiny fraction of what it was, and confirmed again by seeing koko-analytics-collect.php in DevTools > Network with every pageload throughout the site. All this is still happening now, after I reverted back to that version.

    What I added to the wp-config.php file was exactly the define() you posted above, and it definitely points to the right file in the root WP directory.

    Even in v. 1.8.2 (the latest version), why would Koko be able to successfully create the endpoint file (as described in my previous post) but tell me that it couldn’t install it and is seemingly unable to read it? It seems there are still issues here. Thanks!

    Thread Starter roam92

    (@roam92)

    Danny, there are still some strange things going on… I updated to v. 1.8.2 (the latest version) and things fell apart. It told me “The plugin is currently not using an optimized tracking endpoint” even though the file was still there.

    I manually removed the endpoint file and then Created it again through Koko’s Settings, but it gave me the message “Unable to install optimized endpoint: Error verifying HTTP response. Unexpected response headers” even though it *did* successfully create & install the file. However it was still telling me that it wasn’t there in the Performance section of Settings.

    So I added the define() line to the wp-config file and then the Performance section of Settings disappeared entirely, with no info or status given on the endpoint file.

    The problem then is that the stats pretty much shut down on new pageviews, with visitor counting basically stopping. Yikes.

    I rolled back to the 1.7.5-dev version you posted above (basically what I had this morning) and counting works again, endpoint file still there, but still no Performance section showing in the Settings. But most important is that visitors are being tallied again. Whew.

    Anyway, a frustrating experience and I really have no clue what’s going on.

    Thread Starter roam92

    (@roam92)

    OK, thanks – I will upgrade to the latest version just out (I have been using your -dev release till now) and keep an eye on it.

    Thread Starter roam92

    (@roam92)

    Thanks, Danny. I just checked and Koko Settings continues to tell me that my site is using an optimized tracking endpoint. “Great!” I confirmed this in Chrome DevTools as well.

    Also, my AJAX Usage (as shown in the Kinsta dashboard) has dropped off dramatically in the past two days, to a small fraction of what it was previously.

    Should I still add the define() to wp-config.php? Happy to still do that, or I can continue to keep an eye on it.

    Thread Starter roam92

    (@roam92)

    Hi Danny,

    Thanks for your reply. It seems some flaky stuff is still going on with this plugin.

    So I tried DevTools again with a Chrome Incognito window, to make sure nothing was going on with cache or cookies or blocking or exclusions… Then, the Network tab showed admin-ajax.php on pageload, in addition to script.js.

    I thought, that’s strange because Koko told me a week ago that it was using the optimized endpoint and I haven’t touched it since. I checked the hosting web server and the koko-analytics-collect.php file was still there in the right place from before. But nevertheless, the plugin itself was telling me “The plugin is currently not using an optimized tracking endpoint.”

    So I asked Koko to create the endpoint file again from Settings. It said it did, and that it was now using the optimized endpoint again (“The plugin is currently using an optimized tracking endpoint. Great!”). Meanwhile, nothing changed at all on the web server – the same original endpoint file from 2 June was/is still there.

    Now, when I go to a brand new webpage from an Incognito browser window, I do see koko-analytics-collect.php on pageload again, which seems correct. It appears optimized once again.

    But how long will it last? I changed nothing since my previous messages above, yet the plugin’s internal configuration seemed to “fall back” somehow. How could that have happened?

    Thread Starter roam92

    (@roam92)

    Hi @dvankooten, any thoughts or clarity?

    Thanks!

    Thread Starter roam92

    (@roam92)

    Just to confirm – on pageload, the DevTools Network tab now shows a request to /koko-analytics/assets/dist/js/script.js?ver=1.7.5-dev, not to /koko-analytics-collect.php or /wp-admin/admin-ajax.php?action=koko_analytics_collect – is that right?

    Thread Starter roam92

    (@roam92)

    Successfully installed optimized endpoint.

    The plugin is currently using an optimized tracking endpoint. Great!

    So… success! Glad it was finally figured out. What changed?

    Thread Starter roam92

    (@roam92)

    Hi Danny,

    Apologies for the delay; I didn’t notice that this thread rolled over to a Page 2.

    Yes, the site is definitely publicly available to everyone.

    My server allows outgoing requests, AFAIK.

    It’s possible perhaps that the Cloudflare WAF is getting in the way, somehow? But surely Koko runs fine on many sites with Cloudflare, I would think.

    Is there any other way to test or check what you’re looking for?

    What I still can’t understand is how Koko is clearly able to remove that file when it exists already, but not able to see that file when it exists. Nor to create it; only to delete it. How could this happen?

    Thread Starter roam92

    (@roam92)

    Sure, 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"

    Thread Starter roam92

    (@roam92)

    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?

    Thread Starter roam92

    (@roam92)

    Thanks. 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.

Viewing 15 replies - 1 through 15 (of 221 total)