Using GA module in conjunction w/ Domain Access; this appears to only occur when Domain Access is installed.
When specific pages are excluded from tracking, the Google Analytics tracking code is still included on the page. Have not yet verified whether the pages are being tracked (and cannot do that very easily due to time & hosting constraints), but since I've confirmed that the normal behavior is to exclude the tracking code I'm assuming for the time being that they are being tracked, even when excluded.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Screen Shot 2012-08-06 at 2.55.08 PM.png | 19.12 KB | agentrickard |
| #7 | Screen Shot 2012-08-06 at 2.55.18 PM.png | 23 KB | agentrickard |
Comments
Comment #1
escoles commentedAdditional information: It appears to be able to exclude pages by node path, but not by alias.
Comment #2
hass commentedComment #3
agentrickardNot enough information to be actionable. I don't know what "exclusion codes" are.
Comment #4
hass commentedAnd i'm not supporting other buggy modules in this queue.
Comment #5
escoles commented"exclusion rules" referred to the Google Analytics configuration settings under "Add tracking to specific pages".
When "Add to every page except the listed pages" is selected, Google Analytics will only exclude the code from pages that are specified by node path or a node path wild card.
Re-opening and moving back to Domain Access, as I have reason to believe this is a Domain Access issue -- see also http://drupal.org/node/1711872.
Comment #6
agentrickardCan you post your configuration here -- for Google Analytics. Are you trying to exclude by path alias?
Comment #7
agentrickardInteresting. I cannot replicate this report. Aliased pages are properly excluded.
Pic 1 here is the home page, which has analytics enabled. (The debugs are from _googleanalytics_visibility_pages()). Pic2 is an excluded page.
Do you happen to be using Domain Path?
Comment #8
escoles commentedYes, I was trying to exclude by path alias.
Google Analytics is currently disabled on that site. Between this and the related issue with block inclusion/exclusion, I had to disable it (it was logistically much easier to manage using the block system than with Google Analytics), so I can't very easily give you the config for the Google Analytics module. Is there anything particular you want to know about it? I can tell you that each domain was configured with a different account ID, that the problem was observed with Google Analytics caching both on and off, and that I was tracking by role (anon users only). Basically, the Google Analytic equivalent of how I configured the blocks I used to replace the Google Analytics module (see http://drupal.org/node/1711872#comment-6316776).
Comment #9
agentrickardRight. I could not replicate this issue -- see comment 7 above. I wanted to know what your exclusion paths are, but I tried for a normal path alias and it worked fine.
I suspect some other module or process is interfering. Do you have any other URL rewriting modules? Common ones in your case would be Global Redirect and Domain Path.
Comment #10
escoles commentedDomain Path and Global Redirect are both enabled. Might be able to get away with disabling Global Redirect on this site, as it's intended to be totally un-spidered. (The site in question is basically a server for advertising landing pages.)
I'll have to update & test my dev site before I can test disabling those; will need to get back to you.
Comment #11
agentrickardI suspect the issue is with Domain Path, then. I think there is a similar issue in the queue there already.
Comment #12
agentrickardI think this is related to #1706560: Support for Global Redirect and #1493318: Domain Path doesn't trigger active menu CSS. Moving to the other queue.
The problem is likely how Domain Path alters the $path variable, which makes it so that alias-lookups fail when GA (or the blocks system) tries to find matches. See domain_path_url_inbound_alter().
I would prefer to fix this in 7.x first. But if you find a fix in 6.x, please post it here.
Comment #13
agentrickardLet me point out that this is not really a bug. Consider what you are trying to do: establish unique path aliases on a per domain basis. As a result, some of your aliases are not stored in the {url_alias} table.
Logically, this is why you can't use an alias consistently in block or GA settings. We can try to correct for that, but it will very likely break other parts of Drupal.
Consider this a case of feature trade-off. If you want per-domain aliasing, you may lose the ability to use one alias for matching rules.
You should also try entering all the aliases for a path and see if that helps.
Comment #14
escoles commentedRe. bug, understood. But not sure what you mean by 'all the aliases' -- are you referring to a case where a page has multiple aliases? Or are you counting both the alias and the node path? If the latter, I have found that the node path is sufficient, so entering both will always work -- though that would improve the administrative workflow a little (by keeping the alias physically adjacent to its node path, thus eliminating a need to refer to other sources for the node path).
Comment #15
agentrickardYes, a case where a node has multiple aliases.
I'm assuming, in your case, that an path like 'user/escoles' works, but a path like "content/foo" might fail.
I'm not sure what you mean regarding the admin workflow.
Comment #16
mably commented