Koko having trouble with optimized endpoint file

  • Resolved roam92

    (@roam92)


    1 week, 4 days ago

    After upgrading to version 2, under Settings, I see:

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

    …even though the endpoint file is still there from version 1. So, I click the “Create optimized endpoint file” button again.

    The plugin then re-creates koko-analytics-collect.php, still in the right directory and with the right permissions, but somehow cannot seem to recognize it. The Settings page returns (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 all pages, 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, many thousands.

    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.

    How can Koko’s Settings create the endpoint file but not seem to recognize that it’s there? Thank you!

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Danny van Kooten

    (@dvankooten)

    1 week, 3 days ago

    Hello @roam92,

    Koko Analytics can create the optimized endpoint file, but it fails verifying that it actually works because an HTTP request to the file does not return the correct HTTP response headers. This could have any reason and depends on your server set-up, it’s impossible for me to tell from here or even from within the plugin code. Hence why Koko Analytics plays it safe and uses the method that is guaranteed to work and only switches to the slightly faster method when it is absolutely sure that that method is working.

    I hope that explains. Just know that it is perfectly valid to use the AJAX endpoint and the difference in performance should only matter for very bloated sites or insanely high traffic sites.

    Best,
    Danny

    Thread Starter roam92

    (@roam92)

    1 week, 3 days ago

    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.

    Plugin Author Danny van Kooten

    (@dvankooten)

    5 days, 15 hours ago

    Hi @roam92,

    Ah, I’m sorry, I didn’t remember our previous conversation on this. Now I do and I read through the previous thread to see what we tried already. Looking at the latest error that you’ve been getting the issue is that something in your server is causing the endpoint not to work.

    After Koko Analytics creates the file and performs an HTTP request to it, the server response is 403 Forbidden. It is impossible for the plugin to tell what is causing this and how it can be remediated, because it could be coming from anywhere in the request-response chain.

    You can always try to manually set-up the endpoint and modify your server configuration accordingly so that it works, but it’s impossible for me to tell what steps you need to take for this.

    • 1. Fix/modify server configuration so that a PHP file in your WordPress root directory runs without issues.
    • 2. Allow Koko Analytics to try to install the endpoint again. Alternatively, create it yourself with the correct file contents.
    • 3. Set the KOKO_ANALYTICS_CUSTOM_ENDPOINT constant to the file you just created to force-use it (and bypass the periodic verification check).

    It could be that all you need to do is step #3, but I would take great care in checking that pageviews are actually still being recorded because Koko Analytics will no longer periodically check whether the file is working.

    Best,
    Danny


Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.