- Issue created by @ishore
- Assigned to chetan 11
- last update
9 months ago Build Successful - Issue was unassigned.
- Status changed to Needs review
9 months ago 7:41am 26 February 2024 - Status changed to Needs work
9 months ago 9:49am 26 February 2024 - 🇨🇭Switzerland berdir Switzerland
Seeing this too.
This doesn't seem to adress the warning in TagContainer->getConsentMode(), which may very well go away after resaving the settings, but there should either be an update function or runtime logic to handle the setting not being there.
- Status changed to Needs review
9 months ago 7:15pm 26 February 2024 - 🇨🇭Switzerland berdir Switzerland
Ok, TagContainer is an operator precedence issue, ternary operations are weird like this: https://3v4l.org/b9Rt5
Fixed that, but I think this is still a bit of an issue, because existing sites will now implicitly default to TRUE as there is no upgrade path to keep the existing behavior. Maybe there should be a post update like google_tag_post_update_move_advanced_settings() that initializes it to FALSE.
Reading the change in validateGtmFormValues() again, I think it's valid, still think it might not be necessary to be this elaborate. $form_state->getValue() has second argument that could be set to an array and then it could use
foreach ($advanced_values['gtm'] ?? []
and drop the condition there entirely, but I don't know about the changes to the loop, pretty sure those are _not_ necessary, but leaving for now. - last update
9 months ago Build Successful - 🇺🇸United States japerry KVUO
The reason why its set to TRUE by default is because Google asked it to be the default for all tags. Originally, we weren't going to make it even configurable, but after consulting with the Google engineering team, they said there were some cases where it'd be good to disable it.
Thats also why there isn't an upgrade hook, because if its null (existing site), we default it to true.
- 🇨🇭Switzerland berdir Switzerland
There's a difference between being default for new installations (which I fully agree with this makes sense) and changing the behavior for existing sites (in a patch release). I'm not even sure what it does exactly, but I suspect I'll have to look into it with some of our clients that have their own teams that manage their tag manager and configure things in combination with third party cookie banners.
Either way, the behavior here isn't changed, this is just fixing the undefined array key warning.
- last update
9 months ago Build Successful -
japerry →
committed a9cea9f8 on 2.0.x authored by
chetan 11 →
Issue #3423718: Array warnings after upgrade to 2.0.3
-
japerry →
committed a9cea9f8 on 2.0.x authored by
chetan 11 →
- Status changed to Fixed
9 months ago 9:48pm 27 February 2024 - 🇺🇸United States japerry KVUO
Yah, the MR looks right. Committed!
Regarding True vs False: The problem with existing sites is that if its not set to true (in most cases), their sites will stop (or dramatically reduce) reporting on March 6th. So having an upgrade path that sets the setting to false for existing sites would put their configuration into a non-desirable state, and they may not know which setting they have to explicitly set.
- 🇸🇦Saudi Arabia ishore
No warning messages for me now after latest update (2.0.4), thank you!
Automatically closed - issue fixed for 2 weeks with no activity.