Problem/Motivation

Google Tag module does not work with domain access initially

Proposed resolution

Added hook_domain_batch which allows domain environment overrides for Google Tag settings

Original report by generalconsensus

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

generalconsensus created an issue. See original summary.

generalconsensus’s picture

knalstaaf’s picture

Status: Active » Reviewed & tested by the community

Seems to do the job for me. After the patch is applied, there's an extra GTM tab available in the settings of each domain (admin/structure/domain/view/*/config).

solotandem’s picture

Version: 7.x-1.0 » 7.x-1.x-dev

Is this a moot point with the recently added support for variable module, and realms, and domain_variable? If not please provide details.

oldspot’s picture

I have tried applying the patch to both the latest version 1.1 and to 1.x.dev and no luck.
It looks like the way the code is loaded on the page has changed quite a lot and it's now loaded from a snippet file which gets created on saving the settings. This means that no matter what domain you are on when saving the configuration form you will simply be overwriting the snippet file with your latest tag code.

Besides that, the 'fieldset' functions have now been removed and converted into one 'parent' fieldset function which handles the different fieldset types:

$general = google_tag_general_fieldset($form_state);
$tag_path = google_tag_path_fieldset($form_state);
$roles = google_tag_role_fieldset($form_state);
$statues = google_tag_status_fieldset($form_state);
$advanced = google_tag_advanced_fieldset($form_state);

Although I think even rerolling the patch would not do much of a difference due to the snippet file issue.

I think going down a route similar to the patch in this issue https://www.drupal.org/node/2843183 might work, although I haven't tried anything yet.
So saving a different snippet file per domain, the same way they save one per language code.
I will look into creating a new patch as soon as I can.

oldspot’s picture

Status: Reviewed & tested by the community » Needs work
criscom’s picture

Only version 7.x-1.0 works for me on multi domain sites geared by domain_access. After updating to 7.x-1.1, 7.x-1.2-rc2 and the latest 7.x-1.x-dev it didn't work for me any more. I haven't tried the patch, though, as I downgraded back to 7.x-1.0 and with 1.0 I could make it work again.

solotandem’s picture

Would someone please address my question in comment #4? If someone would provide details as to why a certain set of module releases does not support domain access, this would be greatly appreciated. Making statements like "Only version 7.x-1.0 works for me on multi domain sites geared by domain_access" without any supporting information does not advance the issue. (I am not pointing fingers here or picking on one person, but simply using this statement to illustrate the point. And 'details as to why' would preferably include references to specific lines of code.)

The recommendations and claims on the project pages for Domain Access and Domain Variable would lead me to conclude this is a moot issue.

pedrosp’s picture

I had also several issues updating from google_tag 1.1 to further versions and I am also using Domain Access.
I finally got it working (now using latest dev 7.x-1.x) and those were my 2 problems:

1) Error saving config files
problem: all files on site/default/files/google_tag couldn't be accessed by config update (granted to ROOT instead of WWW-DATA)
solution: erase all folders manually through command line and save again config to recreate folders with proper granted user www-data
#2910283-26: public://google_tag cannot be created in some server environments

2) Wrong realm snippet
problem: the realm used is generic language instead of domain variable
solution: added on custom module a hook to force domain realm instead of language
#2880710-12: Google Tag domain conf support as realm

I guess it is possible to somehow modify the module to address those behaviours.

andjules’s picture

@solotandem as per your comment #4, the answer is "kind of".

  • I have a multi domain site that was operating successfully and did not use domain variable.
  • I installed google tag and like others mentioned, it did not respect GTM id per-domain (although it should be noted it did manage drupal features well — roles and page access, etc. — per-domain, and remembered each domain's GTM id in the module configuration interface. But in reality, it served up the same GTM id for all domains on the front end. Whichever domain had been saved last, it uses that domain's GTM id for all the domains.
  • I installed domain variable as suggested and enabled the GTM id variable (this is using 7.x-1.x-dev for google tag and 7.x-1.1 for domain variable). It worked for a little bit but other issues domain variable issues (seemingly unrelated to google tag) started to cascade, with access denied issues to some content... again, the problems seem unrelated to google tag, but I was not using any other features of domain variable.
  • I then realized that I was supposed to deactivate Domain Configuration and Domain Settings and use an under-documented sandbox project to migrate my conf variables into domain variable's tables.
  • So as to your comment in #4, I suppose if I took on an extremely high-risk, under-documented, technical migration of domain configuration/settings to domain variable, maybe this would all work out. However, given that my 5-domain, mission-critical drupal app has worked fine with domain configuration/settings and no other features have required domain variable... this seems like a heck of an undertaking simply to get google tag manager to serve the right GTM ids for each domain. Augh.

Perhaps that sounds like complaining, but I'm really trying to give you feedback on why simply saying "use domain variable" is a very expensive solution for us in terms of hours and learning (it took me quite a while simply to understand the basic differences of domain variable vs domain configuration/setting) and project-risk.

solotandem’s picture

@andjules Thank you for the detailed comment.

I understand your concern regarding the migration from domain_conf/theme to domain_variable. However, after a review of the 'sandbox' code it would seem that your fears can be allayed. The project being in a 'sandbox' state does not necessarily imply it is no good. The code appears sound and has a review and patch provided by an active contributor to the Drupal infrastructure.

To use your words, the patch in #2 'seems like a heck of an undertaking simply to get google tag manager to serve the right GTM ids for each domain'. I am aware of the passion some users have for the domain project. However, its need to overwrite almost everything in core and contributed modules to accomplish its goal is a red flag for me that suggests poor design, bad practice, etc. The domain_variable module is designed to make the variable realm concept work with domain (and does not require hack code in this or any other project). If that module needs some attention, then you and others might want to focus your efforts there (and in the sandbox project).

My test of domain_variable with and without i18n support shows that it does what it purports to do.

TEST: domain realm
modules enabled

  • domain
  • domain_variable
  • variable
  • variable_realm
  • variable_store

site configuration

  • 3 domains
  • domain realm variables: container ID, data layer, environment ID

steps to test

  1. Save the google_tag settings form for each domain with different values for the realm variables.
  2. Inspect the snippet files to confirm the realm variables are used.
  3. Load a page for each domain; confirm the snippet file or source is per domain.

TEST: combined 'domain plus language' realm
modules enabled (additional to above)

  • i18n_variable
  • domain_variable_i18n

site configuration (additional to above)

  • 2 languages
  • language realm variables: container ID, data layer, environment ID

steps to test

  1. Save the google_tag settings form for each domain-language combination with different values for the realm variables.
  2. Inspect the snippet files to confirm the realm variables are used.
  3. Load a page for each domain; confirm the snippet file or source is per domain.

NOTE: It is imperative that the same variables are added to each realm: language and domain. Otherwise the variables will become contaminated for certain realm:key combinations.

solotandem’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Assigned: Unassigned » solotandem
Status: Needs work » Fixed

With the latest commit to the 7.x-2.x branch, there is now a domain insertion condition. The 2.x branch supports multiple containers. Together, that means you can create a separate container for each domain and specify the domain as a condition. And it does not require any of the variable modules nor the domain_variable module.

Who will test the dev release on this branch, on a development environment, of course?

Status: Fixed » Closed (fixed)

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