Hello @ritaantal,
Simply create new cookie group and add that cookie group to list. I presume that you want that cookie group not to be cached?
What’s happening is the plugin u are using s embedding its HTML into the page prior to caching. The plugin should have been smarter to use javascript to trigger its popup request which would make it independent of the caching. There are other GDPR Cookie Consent plugins that are more conscious of caching plugins (via making themselves through javascript).
But if you want to use this specific plugin you could solve your problem by switching cache to Disk mode (instead of Disk Enhanced) and using Fragment Caching. You would add the fragment macro around where the GDPR plugin inserts its code. This way each time users visit the page it triggers that portion while still serving the cache page. win-win.
Dear @fistfullofcrisco,
Thank you for your answer. I have to admit that I’m a no-coder so after and using Fragment Cache. I don’t understand it…
Can you help me with a tutorial maybe?
I chose this plugin because it seems to have the functions I need (e.g. modify your cookie preferences), styling and great support that a non-coder needs. I forwarded your answer to them as well.
I hope to find a solution to this problem soon.
Thanks,
Rita
@ritaantal,
Fragment Cache is the extension in W3 Total Cache which is available in Pro version of the plugin. All you need to know about the fragment caching you can find on our FAQ page here.
Dear @vmarko
Thank you for your reply.
Regards,
Rita
Dear @vmarko and @fistfullofcrisco,
Let me forward you the answer of the plugin developer:
“We are not embedding the HTML prior to caching. In fact, we are scanning and filtering out third-party cookie scripts just before transferring the HTML content from server to browser, and this is done via the WordPress shutdown hook. Additionally, this happens only with our automatic script blocker where we have to scan the scripts just before the HTML is rendered in the browser in order to moderate the latest user consent/updates. We are certain that this cannot be achieved via javascript.
On the other hand, if the W3TC team can share further information regarding their caching hooks and a way to clear/refresh the cache, we can use it to moderate the cookie information based on user consent.”
I would be happy to have your opinion on that.
Kind regards,
Rita
@ritaantal To answer their questions:
We register our own shutdown hook to capture pages for minify and caching. We do this using register_shutdown_hook(). Hooks are fired in the same order as they are registered, and we register ours after the WordPress core shutdown hook is registered, so the WordPress shutdown hook should run normally before ours.
To clear the cache, they can call one of our functions: w3tc_flush_all(), w3tc_flush_post($post_id), w3tc_flush_posts() or w3tc_flush_url($url).
But I’d like to know what issues you encounter. Maybe we can help you set up the plugin correctly to work smoothly with their plugin without disabling Page Cache entirely.
Dear @gidomanders,
Thank you for your kind answer. The problem basically is that if the user “changes their mind” and turns on/off different types of cookies (advertisement – statistical) the modifications don’t work or not reliably.
According to the plugin developer the page caching can cause this.
This is the site: duotone.hu Now page caching is turned on (disk: enhanced mode).
Please have a look.
Thank you for your help in advance.
Regards,
Rita
@ritaantal I think I know what the problem is. They modify the page before the page is cached. This means that they change the page according to the cookie preferences of the user that is requesting the page, and then the page is cached. For visitors requesting the same page after it was cached, the cached page will be sent directly from Apache/NginX to the browser, so the server doesn’t have to start up a PHP process. This means they will not get the page according to their preferences if their preferences are different.
What I explained above is how Page Cache Disk: Enhanced works. If you use Disk: Basic, a PHP process will be started and the cached page will be crawled to check for (page) fragment cache before sending it to the browser. A short explanation:
Fragment Cache and “page fragment cache” dynamically loads content (real-time) on your cached pages by parsing them for specific tags you manually embed. That way the server doesn’t have to build the entire page from scratch.
Using Disk: Basic should also fire the WordPress shutdown hook, so I expect their plugin to be compatible with ours as long as you do not use Disk: Enhanced.
Hi @gidomanders,
Isn’t fragment caching only a paid feature? It is not affordable for me or my micro-business clients…
Thanks for your help 🙂
Rita
@ritaantal Fragment cache is a premium feature, but page fragment cache is not. I’ve actually been working on an FAQ item about page fragment cache. here’s the part of it that explains the difference with Fragment Cache:
“Page fragment cache” dynamically loads content (real-time) on your cached pages by parsing them for specific tags you manually embed. Despite the naming, this feature should not be misunderstood with “Fragment Cache”, the premium feature. “Fragment Cache” extends the transient API in WordPress to provide caching and purge policy management for fragments you manually create. It also enables fragment groups, defined by a plugin or theme, which include common operations to be cached using transients.
Hi @gidomanders,
Does that mean that I set page caching to Disk: Basic and don’t need to do anything else?
I tried it and now turning advertisement cookies on and off work well, however, there are still problems with statistical cookies (I use self hosted Google Analytics). But that might be an issue within the plugin.
My pingdom score is 100% and load time is 925ms so I hope I’m getting closer to the right combination…
Thank you again for your help.
Rita
