Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#2 | 2816177-google-tag-domain-access.patch | 4.95 KB | generalconsensus |
Comments
Comment #2
generalconsensus CreditAttribution: generalconsensus at Forum One commentedComment #3
knalstaaf CreditAttribution: knalstaaf commentedSeems 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).
Comment #4
solotandem CreditAttribution: solotandem commentedIs this a moot point with the recently added support for variable module, and realms, and domain_variable? If not please provide details.
Comment #5
oldspot CreditAttribution: oldspot at Zoocha commentedI 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:
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.
Comment #6
oldspot CreditAttribution: oldspot at Zoocha commentedComment #7
criscomOnly 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.
Comment #8
solotandem CreditAttribution: solotandem commentedWould 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.
Comment #9
pedrospI 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.
Comment #10
andjules CreditAttribution: andjules commented@solotandem as per your comment #4, the answer is "kind of".
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.
Comment #11
solotandem CreditAttribution: solotandem commented@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
site configuration
steps to test
TEST: combined 'domain plus language' realm
modules enabled (additional to above)
site configuration (additional to above)
steps to test
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.
Comment #12
solotandem CreditAttribution: solotandem commentedWith 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?