i switched to not proxied approach which is working
Are you now running 2.5.4 without proxy? Or 2.5.0?
the tracking stopped working when the proxied JS was not available anymore for me.
Can you try the following?
Visit your site’s frontend in a private window (or regular, as not as you’re not logged in as an administrator) and append ?plausible_proxy=1 to the URL.
Hitting enter will make the page reload with the Proxy enabled, just for you.
Please verify if the /wp-content/uploads/b07b73caa0 directory exists. If not, check if the uploads directory has 0755 permissions using SSH/SFTP. If the directory does exist, check if it has 0755 permissions, too.
If the directory doesn’t exist, please also check if there’s another directory with a name of 10 random letters and numbers. If that’s the case, then it’s possibly a database or page caching issue, and your cached pages are calling an old path.
okay, I had a problem with the non existent JS in the uploads dir.
I remember having deleted that ambiguous file when i was doing some security hardening a month ago. some hash-named JS file in uploads dir looks suspicious.
i could now switch on and off several times the proxy setting and a hash-named JS file got created again. (on both version 2.5.0 and 2.5.4, i previously rolled back now i am up again)
so permissions to create that file are mostly fine.
i tested the URL param ?plausible_proxy=1 with inactive proxy setting in WP. but that didnt created the JS file as it seems. 404 again.
BUT still what i have with active proxy setting are 500 errors on POST request. they contain tracking payload.
some hash-named JS file in uploads dir looks suspicious.
Yes, problem is that we can’t name it plausible, or anything familiar, because then it’d get flagged by Ad Blocker lists, which affects your analytics. That’s why we inform you of the folder and filename in the plugin’s settings screen.
BUT still what i have with active proxy setting are 500 errors on POST request. they contain tracking payload.
500 errors are always logged in your PHP error log. Could you look up the related error and share it here?
that makes totally sense with the hiding. And yes there is a message informing about that! But remembering that is another tough thing to do.
500 errors are always logged in your PHP error log. Could you look up the related error and share it here?
Okay, i never worked with the WordPress error log. Luckily my hosting provider has a nice error log UI and i dont need to set up anything around that.
I found a Fatal PHP Error! Which I really did not expect to have something to do with that. Also i wasn’t recognized that anywhere else, all other things seemed to continue to work fine.
There is a location in the code where class MyCustomField extends acf_field acf_field class gets extended. So its depending on the famous ACF plugin. Everything was working fine with that but somehow not when the REST call was made, i assume.
I fixed by just skipping that code with:
// If ACF isn't active for some reason, fail gracefully. if (!class_exists('acf_field')) { return; }
So actually it started with one problem and turned into another.
So thank you for helping me out that fast with your good ideas and remote debugging skills!