tomalec
commented
7 months ago Hi @toktor, thanks for early adopting the latest changes and for the detailed report :)
Supporting WP Rocket may be tricky. I haven't investigated it deeply yet, but from a high level, there may be more problems than just consent mode if the plugin turns every page into a static one.
The way the extension works is that it adds inline JS with dynamic data for each page, which may contain information about products added to the cart, purchases, etc. Before 2.0.0 (before consent mode support), it was even more dynamic, as the extension was inlining gtag calls depending on the state. So, having the pages cached could result in irrelevant things being tracked.
As per the consent mode itself:
The idea behind the default state = the thing our extension set = gtag('consent', 'default', {...} ), is that it represents your site configuration, and the consent set on the page loaded, before the user takes any action and before any event is tracked (even the page_view).
Then the consent could be updated in the page run-time, using gtag('consent','update',{...}) according to a user changing their consent via banner, loading their preferences, etc. (we do not implement any gtag('consnt','update'... in WCGAI).
So, speaking of potential solutions:
- Do I understand correctly that you suggest removing inline JS and replacing it with a blocking
<script src="file.js">wherefile.jswould be dynamically created on the PHP side to contain consent modes? - AJAX call for
defaultsetting could be trouble some due to the logic I explained above. To respect the Google API rules and users' rights, we'd have to hold all the actions and all the tags from our and other extensions until the AJAX response comes. I cannot imagine the way to do so. (but I'm always happy to be proved wrong :) ) - Adding a filter in JS seems more doable than above. But if you have access to JS, you can set your own
gtag('consent', 'default',{})after ours, overwriting the settings. Which is the way correct way to use Google's API. So, there is no need for the hook. You can synchronously add your own blocking script that doesgtag('consent', 'default',{ the right one }), and it's done.
AFAIK The fallowing is the right way to use the Google's API and should work fine
<script>
// WCGAI code with "wrong" defaults
gtag('consent', 'default', {
'analytics_storage': 'denied',
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'region': ['PL', 'ES' /*...*/]
});
</script>
<!-- later in the document, in your blocking script -->
<script>
// your code, with the "right" defaults
gtag('consent', 'default', {
'analytics_storage': 'allow',
'ad_storage': 'allow',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'region': ['PL', 'ES' /*...*/]
});
// ... asynchronously, after AJAX, the user click, whatever
gtag( 'consent', 'update', {
'analytics_storage': 'allow',
'ad_storage': 'allow',
'ad_user_data': 'allow',
'ad_personalization': 'allow',
});
</script>Thanks for giving the context and mentioning Complianz. I still have it on my to-do list to investigate the integration with them more deeply, but we planned that for v1 or v2 of consent mode. We wanted to ship MVP and basic manual/hook-based configuration ASAP.
Could you elaborate a bit more on how you do that bridge and what and why does not work together?
toktor
Describe the bug:
When using WP-Rocket and caching enabled, we can not change the consent state via woocommerce_ga_gtag_consent_modes filter. The issue lies as the consent mode is included as inline JS and WP-Rocket creates static files for each page where we can not change the inline JS.
Steps to reproduce:
Expected behavior:
Actual behavior:
Additional details:
Possible proposed solution:
Simplest solution would be to change this JS (or at least consent part) to be included JS file. In this case we can exclude it from caching separately.
Alternative method would be to include Consent States with JS only and not have them come from PHP. Ex. Ajax call to wp-admin to add consent settings.
Third option would be to find a filter in JS that runs the event code and attach to this. So while we do print "wrong" consent modes in the html, we can listen with JS once the code starts running and modify the consent states on the fly when they are sent - without touching the html.
Background: We have created a bridge to use Complianz plugin to manage consent itself and we are using WGAI to show consent. That means we have a bridge that sends consent from Complianz to WGAI but as of not, we cant update consent properly. We cant use Complianz either to manage consent in tags as it does not work together with WGAI. But I assume this issue would be with any of the caching and consent plugins/solutions where we need to update the consent dynamically.
Please let me know if I have understood the problem correctly. I can propose a solution/code modification, if the possible solution is something that makes sense.
Please let me know if this bug-report does not belong here or should be somewhere else.
EDIT: I missed the part where it is recommended to update on-page consent with gtag. We can do this but the default page state update would still be nice.