Enforce Privacy Consent Policy checkbox default value is checked even when it is disabled

Please review the fix in MR.

I have same issue

Oops! sorry i didn't mean to overwrite the issue summary.

Since this is a no brainer one line change, let's RTBC.

Adding static patch to issue so we can use in build tools without storing it locally.

Patch #9 works for me

Works for me also.

Since this checkbox can cause google analytics to outright not work on sites that need this option disabled, and given that someone can very easily visit this configuration page while GA is working, notice the box is checked, and assume nothing needs to be done with it before saving, I personally consider this bug to be Major.

The patch in #9 solved this for me.

I note that in the relase notes here: https://www.drupal.org/project/google_tag/releases/2.0.3 → it states that

Starting March 6, 2024 tags that use certain features from google that require consent mode will not work properly unless the code is set as on by default.

I think this might be why our Google Tag Manager and subsequent Google Analytics stopped working over the last couple of days.

Any chance of a new tagged release with the above patch?

+1 RTBC

Merge Request #72 works for me.

Eduardo Morales Alberti → made their first commit to this issue’s fork.

The consent_mode is a boolean https://git.drupalcode.org/project/google_tag/-/blob/2.0.x/config/schema...

google_tag.advanced_settings.consent_mode:
  type: boolean
  label: Consent mode

So we should add a hook update to add the property to FALSE, and then leave the users to choose if enable it or not, and save it as a boolean.

Added gitlab-ci

^^ Be aware that the last two releases → (2.0.3 and 2.0.4) include updates to add consent mode, and crucially in 🐛 Config schema missing for consent mode Fixed to enable it by default when updating the Google Tag module, which seems deliberate (even if probably every person coming to this issue would disagree with that decision).

Updated title to quote checkbox name since it could have been read as a request to enforce that the checkbox is checked.

Wouldn't this code automatically update the consent mode checkbox to be unchecked even in cases where uses wanted it to be checked?

/**
 * Update google_tag containers and set the consent_mode to FALSE.
 */
function google_tag_update_8202(&$sandbox) {
  $entities = \Drupal::entityTypeManager()->getStorage('google_tag_container')->loadMultiple();
  /** @var \Drupal\google_tag\Entity\TagContainer $container */
  foreach ($entities as $container) {
    $advanced_settings = $container->get('advanced_settings');
    $advanced_settings['consent_mode'] = FALSE;
    $container->set('advanced_settings', $advanced_settings);
    $container->save();
  }
}

I think we should only explicitly set consent mode to FALSE here if the config is empty. If it's TRUE leave it.

This checkbox doesn't exist to just to break Google Analytics on sites. Per the 2.0.3 release notes → sites that need consent mode enabled will have GA break without it.

No matter what we do here there will be users who update the module and end up with broken GA, but we need to do our best to ensure the following:

1. Users who are updating from <=2.0.2 have the checkbox unchecked by default.
2. Users who are updating from >=2.0.3 and have not touched the consent mode config from what is already provided (i.e. "enabled") have the checkbox checked by default.
3. Users who are updating from >=2.0.3 and appear to have explicitly set the config will have that setting persist.

If it's not possible to determine whether the checkbox was deliberately checked or unchecked then 2 and 3 would be impossible to implement together, in which case we'd need to pick one. We'd then need to explain the issue in the release notes and possibly the project page to maximize visibility.

@caesius It is difficult to determine the default value on the update, in 2.0.3 was impossible to "disable the consent mode", so some users probably enabled it by omission and then it is not possible to know what it should be.
Also, the consent mode is a breaking change, from a user that does not want it, should we force to enable it?

As you said, the best option is leave it clear on the release notes.

Upload patch file with last changes

I believe the best patch for anyone experiencing this issue is #9. It's a one-liner and very straightforwardly allows you to just go in and uncheck the checkbox in question without it resetting the next time you open the page. The setting itself will work as expected.

I would not recommend using #25 (or the merge request it's derived from) in a production environment since it includes a database update hook. The module maintainers could very easy roll out another stable release with a different update hook that's named identically.

#9 works for me

Let's bump this to critical because this can mean data loss if you upgrade to 2.0.4 and consent is turned on with GA4 you will stop getting analytics.

Also, #9 is simple enough to fix the saving bug, but maybe the MR that @Eduardo Morales Alberti is working on might be a better fix in the long run...

It doesn't appear that the module maintainers have taken notice of this critical issue yet. I'll reach out to them.

Thanks caesius for reaching out. Since google tag and google analytics isn't a 1-to-1 link anymore, there isn't really a way to autodetect GA4 via a tag.

I've submitted the feedback from this issue to Google to get their thoughts on it. However, my understanding of it now is that it should still default to ON, requiring manual intervention to disable it. So while patch #9 is close, we need to set the default as well. I've created a new MR which should do the following:

* Old & New containers will get the checkbox and consent mode set to on by default.
* Users can disable the functionality by unchecking the box or setting their consent_mode on the config entity to FALSE. Once saved, containers will respect the setting of the checkbox.

Additionally we can add documentation for users ONLY using GA4 that they should uncheck the box if they are having data issues.

Discussed more with Google today, which agrees with the logic of patch #9. Updated the MR: https://git.drupalcode.org/project/google_tag/-/merge_requests/78.diff

Consent support should be enabled when a Consent Management Platform (CMP) exists to provide a consent banner. When enabled, we default consent to 'denied' and execute first so a banner can override this setting if a user opts in.

If you do not enable consent mode and don't live in EEA, nothing should happen, including regressions to existing configurations. If you're in the EEA however and do not enable consent mode, you will get no data, even if you use a CMP because you don't have the defaults set to denied.

Hi thanks I kindly suggest release a new version with MR asap as it really breaks the sites as reported here as well:
https://www.drupal.org/project/google_tag/issues/3393917 🐛 Google Analytics script is not loading. Active

I agree that getting this into a 2.0.5 release asap is critical. Also, information regarding consent mode (and perhaps a mention of this bug) should probably be included on the project page. Since 8.x-1.6 has been out for about 16 months, maybe that "critical notes" section can be replaced? (keeping project pages short is important IMO)

Any plans for tagging a new release soon?

Following up on tagging a new release. :please:

Just found another site that hit this problem.

Could we please get a release with this fix? Thank you.

While I wait for a release, is the "Hot fix" to visit the settings page /admin/config/services/google-tag and uncheck the "Enforce Privacy Consent Policy" settings and hit save?

NicholasS: I can confirm that yes, simply unchecking the checkbox and hitting the "save" button does fix the problem, you just have to be careful if you make any further changes to that page that you always uncheck that checkbox before you hit 'save'.

FWIW you could probably also manually change the config file and import the configuration, or make the change via "drush config:set".

Adding my request for a new release. Just dealt with a client who lost 2 days of analytics because of this.

❤️ Thanks! Yeah had to wait for the reporting delay but reports are showing traffic now again after a ~20 day flatline!

Bumping this.

Can we get a release soon?

Fix on dev branch works for me on Drupal 10.2.5. Lost about a month of tracking data. Not happy.

Bumping as well.

Any chance of a module update this week? I would rather wait for a proper release than patch hundreds of sites.

We have had dozens of issues with sites stopping tracking data because of the form issue. Lots of unhappy people.

Appreciate all the work everyone has done thus far on this thread!

If anyone needs a composer require command that'll grab the dev version until a stable version is tagged, this should do it.

composer require "drupal/google_tag:^2.0.5 || ^2.0@dev >2.0.4"

Also, this module is supposedly maintained by Acquia and yet they don't seem to be aware of this issue that's affecting non-EEA clients. If anyone has a line to Acquia to let them know that a module they supposedly maintain has a critical data loss issue in the latest stable version, maybe that'll prompt a stable release to be tagged.

And just to clarify the underlying issue: It does seem that updating a site from <2.0.3 to 2.0.3/4 may automatically evaluate consent mode to be enabled for existing containers even if the form is never touched, at least from looking at the updated code.

So for non-EEA clients where the whole "consent mode" thing was likely never an action item, this bug seems bound to affect anyone who updates the module if they don't manually go in and uncheck the checkbox and then export configuration. In other words, vendors simply doing their duty to update modules to the latest patch version will inadvertently trigger analytics data loss when they push to production.

There's been a lot of comments already about data loss and requests for a new release, but just pointing out that the affected audience is probably significant.

Yes that's exactly what happened to me. The consent checkbox was unticked, I updated the module as part of routine monthly maintenance. The bug caused it to become ticked without my knowledge. Fast forward a month and the client asks "why do we have a flatline of GA data for April?". Pretty serious bug IMHO.

What camslice describes in #54 happened to me and my client as well. about 30 days of data is gone after the update was made

2.0.5 is out now, which hopefully resolves this for everyone!

Thank you so much Jakob!

Thanks!

Thank you Jakob!

Automatically closed - issue fixed for 2 weeks with no activity.

Also, this module is supposedly maintained by Acquia and yet they don't seem to be aware of this issue that's affecting non-EEA clients. If anyone has a line to Acquia to let them know that a module they supposedly maintain has a critical data loss issue in the latest stable version, maybe that'll prompt a stable release to be tagged.

Andrew @caesius I have such a line to Acquia...and used it recently for another Module-related inquiry. I received great customer service from support staff on my issue, but I also got the impression that they're hands-off in regards to this Module. and for them, this might have been a one-time project rather than an ongoing affair. Their name remains as an honorary chairman type of thing.

I was blown away when I read Acquia claim credit for releasing this Module two years ago...I wasn't aware of this:
https://www.acquia.com/blog/google-tag-module-drupal

I was also very suprised reading them tout the great achievements of this Module, and I wondered if they have any idea what's going on here. A total sense of disconnect from reality.

The problem is the use of the word "Supporter" in relation to this Module because it might give an impression that they're more involved than they really are.

Also, this module is supposedly maintained by Acquia and yet they don't seem to be aware of this issue that's affecting non-EEA clients. If anyone has a line to Acquia to let them know that a module they supposedly maintain has a critical data loss issue in the latest stable version, maybe that'll prompt a stable release to be tagged.

Andrew @caesius I have such a line to Acquia...and used it recently for another Module-related inquiry. I received great customer service from support staff on my issue, but I also got the impression that they're hands-off in regards to the management of this Module.

I noticed there was an Acquia employee in this thread: japerry, so hopefully feedback is going back and forth.