Contrib.social

Make it easier to leverage config overide system

Open on Drupal.org →
Created on 26 April 2024, 8 months ago
Updated 24 June 2024, 6 months ago

Problem/Motivation

Prior to 2.0.3 we could leverage the configuration override system to keep our GTM ids as environment variables and out of configuration / the website codebase.

In 🐛 inconsistent _ga cookie behavior with version 2.x Fixed advanced_settings.gtm was changed to a sequence keyed by the tag id.

So while previously leveraging config override was simple with something like :

$config['google_tag.container.default']['tag_container_ids'] = [
 // Value from env var here...
];

We don't really have a way to still keep container IDs outside of config and configure the advanced settings through config.

Now - I totally accept that

  • almost all sites will be fine using config for ids
  • there is no security reason to keep ids out of config
  • the config override system does not use overridden values for configuration forms - and now the config form depends on knowing if an id is a gtm id meaning I would essentially be asking for a broken ui when using overridden config.

We do it currently because a client operates a number of Drupal sites based on a distribution, and they have management of certain variables outside of the codebase. Some of which we configure at the distribution level and not per site - GTM settings being 1 of them.

It feels like the expectation of using config overrides for ids is not supported by this module?

Would be interested in if anybody else has a use case for using config overrides or alternatives that would still allow us to manage what the id is outside of the config.

💬 Support request
Status

Active

Version

2.0

Component

Code

Created by

🇳🇿New Zealand ericgsmith

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @ericgsmith
  • Comment 6 months ago →
    🇳🇱Netherlands casey

    We are having the same issue.

    For now we simply clean out 'advanced_settings.gtm' manually in our google_tag.container.default.yml:

    ...
advanced_settings:
  consent_mode: false
  gtm: {  }
...

    This is possible as TagContainer::getGtmSettings() returns a default config array. We don't need to override these defaults (not up until now at least).

    I do hope however a better solution will be found. Maybe a single google_tag container entity should only have a single GTM id?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024