search

ibericode / koko-analytics

Privacy-friendly, open-source and lightweight analytics for your WordPress site.
https://www.kokoanalytics.com/
GNU General Public License v3.0
366 stars 30 forks source link

Failed opening required /public/src/functions.php #105

Closed flowdee closed 3 years ago

flowdee commented 3 years ago

Hey @dannyvankooten,

my hosting's error log is getting spammed with tons of these log entries:

2020/12/02 17:29:56 [error] 47173#47173: *16149 FastCGI sent in stderr: "PHP message: PHP Warning: require(/www/my_project/public/src/functions.php): failed to open stream: No such file or directory in /www/my_project/public/koko-analytics-collect.php on line 11 PHP message: PHP Fatal error: require(): Failed opening required '/www/my_project/public/src/functions.php' (include_path='.:/usr/share/php') in /www/my_project/public/koko-analytics-collect.php on line 11" while reading response header from upstream, client: 186.31.210.122, server: myproject.com, request: "GET /koko-analytics-collect.php?p=3028&nv=0&up=1&r= HTTP/1.0", upstream: "fastcgi://unix:/var/run/php7.4-fpm-myproject.sock:", host: "myproject.com", referrer: "https://myproject.com/themes/theme-name/"

Any idea what this could be?

The server runs PHP 7.4 as you can see. May this be an issue?

dannyvankooten commented 3 years ago

Hey @flowdee,

It's definitely not due to PHP 7.4.

It looks like this file is not resolving __DIR__ correctly to follow the actual location of the file, since that file is supposed to be symlinked to your webroot. Can you check whether that file is still a symlink?

What happens if you delete the /www/my_project/koko-analytics-collect.php file and visit your dashboard page just once. Does the file-reappear and does the error message return in your log?

flowdee commented 3 years ago

Nope, the file is gone and not being re-created.

Also tried to deactivate and activate the plugin again.

dannyvankooten commented 3 years ago

OK - great. That should be due to the plugin now detecting that the file isn't working correctly and thus deciding not to use it. Tracking should now use the default /wp-admin/admin-ajax.php endpoint, which shouldn't throw the error you were seeing.

So still not sure why this occurred for you, but it should be fixed now going forward.