Make module compatible with domain access

There is a patch for basic support without using hook. Just checking, whether domain module is enabled and getting active domain id for adding it to the filename.

Re-rolled the patch against latest dev.

I agree it's a workaround and it should be something more permanent. Instead of having a dependency on domain, an alter to change the filenames would be better.

Though I'm not sure why each domain should have a unique js file.

And of course I forgot to attach a new patch...

@spadXlll @andypost

I would appreciate if this does not create like files for every domain, since there are websites with many domains.

Im not sure if this is what your patch does? what are your thoughts?

The patch is unacceptable [no patch should be necessary].

What needs to be done first is for Drupal 8 core to fully implement the 7.x variable project (including variable_realm module) and implement realms properly with an UI, etc. instead of the half-baked partial implementation that exists. [The last I checked this had not been done. If someone knows otherwise please comment.]

Next we restore the 7.x realm functionality of this module. Last, you add a domain realm and configure your sites, all without any special code changes for the domain integration.

@andypost Please read what I wrote. It only refers to 8x.

@andypost:
The latest path is not working. I had to change it:

  public function saveSnippets() {
    // Save the altered snippets after hook_google_tag_snippets_alter().
    module_load_include('inc', 'google_tag', 'includes/snippet');
    $result = TRUE;
    $snippets = google_tag_snippets();
    // Allow to use config overrides to help vary snippets per domain.
    $prefix = \Drupal::config('google_tag.settings')
      ->get('snippets_path_prefix');

If you use $this->config('google_tag.settings') it is not domain sensitive. I was not able to figure out why.

Normally, after saving settings form the snippet file should be created with the defined prefix. However, this wasn't working cause there isn't a form element for the snippets_path_prefix setting.
I'm adding a form element and including this new setting for config save on submitForm.

@andypost et al Do the five recent commits to enable multiple containers provide a solution for the domain context? Can you create a container for each domain and use the config override capability from core to set the correct one? And disable the others? Or remove the other domain items from the attachments added to the page render array?

See #3035196-9: Add support for multiple containers.

Do we have instructions on how this patch should works with domains? Do we have a path forward on how this should work?

@santosh Are you referring to patch in #13? If so, did you read my comment in #15? It suggests that a patch is not necessary but that the latest development release should support domain.

The dev release includes the ability to create multiple containers. Among the commits pushed today is a domain condition plugin that allows you to select the domains to which a container applies.