Well, indeed, the problem arises when activating Varnish Cache. With it disabled everything works fine.
The question now is: can we get Burst to work with Varnish Cache ON?
At the server level I have seen that I can define Varnish VCL exclusions via URL and via Cookie.
Any ideas?
Thank you in advance for your help.
Hi @jablago, I think the problem is that varnish is caching the rest api request.
I have seen that before. We resolved that by adding a time stamp in JavaScript to the end of the api url. This ensures the url is different for each request.
Is it possible you have a setting enabled in varnish that ignores url parameters, or strips them off? If that is the case, switching that option should resolve the issue.
Hi Rogier,
Thanks for answering.
I’m afraid I don’t have much choice with Varnish. I can only activate it, deactivate it, and add URL or Cookie exclusions. And there is no rule for it to ignore URLs.
Could it be something related to the REST API in the WordPress configuration? I have it disabled for Non-Admins via Perfmatters.
I don’t know if that is related to what you say about rest api requests…
As the statistics are tracked using the rest api, it has to be available for non admins as well. Can you try removing that limitation?
I will do that Rogier.
Anyway if I still have issues I will prefer to deactivate Varnish for the statistics work properly.
I really like your plugin and my plan is to install Burst in all of my clients.
Thanks very much for your help.
Hi @jablago,
Thank you for the kind words.
Please let us know if the issues remain, we will look into it and try and make Burst work properly with Varnish enabled.
Hi Hessel,
I’ve been all weekend testing my clients’ websites, both those hosted on Siteground and those hosted on Cloudways.
Finally I have been able to verify that the malfunction is mainly due to the restriction of the REST API that I make in my installations.
In some cases I had also issues with Varnish, but they are solved by purging the data once Burst is installed.
Now I have everything working properly (for now).
I’m a bit exaggerated with security issues, maybe, I don’t know. Experts generally recommend it as a good practice to prohibit access to the REST API to all users except the administrator. Is this really a good practice? What do you recommend?
Thank you very much for your help.
Using the rest api for ajax requests is the best practice method for such requests.
We prefer it over the admin-ajax.php method, which is actually an admin environment. The is_admin() function returns true here for example, although this does not imply admin capabilities of course.
Using the admin-ajax path would not offer more security.
If you want, you can allow only the burst api path, tightening security. This is actually an advantage over the admin ajax method, as it is much harder to lock down admin ajax on request basis. And often overlooked as access point.
Understood Rogier.
Thanks very much for your excepcional support and recommendations.
Have a nice week! 😉
