How could I dynamically change the visibility setting for the current page.
I think this calls for a drupal_alter hook in _googleanalytics_visibility_pages() function. It should be as easy as adding drupal_alter('googleanalitycs_visibility_page', $page_match); just before returning the $preg_match result.
One could implement hook_googleanalitycs_visibility_page_alter($display) and change to his needs the option to display or not the code on the current page. I'll prepare a patch for this.
What do you say?
Comments
Comment #1
Alex Savin CreditAttribution: Alex Savin commentedA very simple patch for this.
Comment #2
Alex Savin CreditAttribution: Alex Savin commentedComment #3
hass CreditAttribution: hass commentedWhy is there a need to change it dynamically? Paths can be configured statically.
Comment #4
hass CreditAttribution: hass commentedWe already have this dynamic
$page_match = php_eval($setting_pages);
. You can use PHP code.Comment #5
hass CreditAttribution: hass commentedhttp://drupal.org/node/261997 or #260367: Roles Opt-Out Sample PHP Script With Path Settings Functionality Preserved may be of interest.
Comment #6
Alex Savin CreditAttribution: Alex Savin commentedI have thousand of pages (nodes not specific to any role but a custom setting) that shouldn't be tracked on our website. It would be a mess to sett it in that field. And also a php code would also be messy. I have a lot of logic behind the decision to track the current page or not.
The links you posted, aren't they a reference to role based visibility? My problem today was that I have to opt out some (thousands) unspecific pages from being tracked.
Comment #7
hass CreditAttribution: hass commentedThe example is for roles, but can be rewritten to archive your specific needs. You may also call your function from the php code snippet to make it not messy in the textarea.
Sounds really strange what you are doing there... why are you doing this? You lose so much info... Node specific counters? Why not using events for this?
Comment #8
Alex Savin CreditAttribution: Alex Savin commentedI am obliged to do that because this pages are used by 3rd party websites with whom we have a contract which bans us from using any tracking code on those pages. So those they end up into an iframe on other websites.
If I add php code into the textarea (although I really hate doing that ...) I can't anymore add independent pages into it that 1) are not part of my function's logic, 2) for which I don't want to create a logic and 3) that are anyhow statically defined.
I don't get it why to complicate things when it can be as easy as implementing a hook_alter that alters the visibility decision on the current page. I find it much easier than to create a function that is called from a code snippet added into a textarea in the front end. Moreover ... I hate mixing frontend with backend like that because 1) it makes it much harder to maintain when working into a multi-dev environment, 2) somebody might overwrite that varibale by mistake and 3) a content manager might need to add pages there that should not be tracked but can't do it because he sees a PHP code snippet that he doesn't understand or, even worse, deletes it to add his list of pages.
I see that field more for content managers or somehow technical staff that don't have to know PHP to add a simple path.
I don't see why 3rd party modules should not be able to alter this decision (to track or not to track the current page).
Comment #9
hass CreditAttribution: hass commentedThe plan was to make visibility 100% compatible with block visibility. This works great for a very long time and has the most flexibility. If core changes GA will follow core. Are you aware of such a hook feature in core blocks visibility?
Comment #10
Alex Savin CreditAttribution: Alex Savin commentedYes I could by implementing hook_block_list_alter(). Take a look in _block_load_blocks(). If I would overwrite the visibility field of the returned array of object blocks, the visibility field setting from the frontend wouldn't have any power anymore over this settings.
Comment #11
Alex Savin CreditAttribution: Alex Savin commentedAnd it would still be 100% compatible it's only that module settings would take precedence over the frontend setting which is set usually by content managers/administrators which are not always programmers.
Through this hook a programmer could impose the displaying of the code on some pages but still leave the content administrators the possibility to easily modify it for other pages.
Comment #12
Alex Savin CreditAttribution: Alex Savin commentedI guess this feature is not wanted but maybe a different implementation would make it more desirable? For those large websites that don't have a webmaster/content manager that has PHP knowledge this would really be a nice to have feature.
Comment #13
Alex Savin CreditAttribution: Alex Savin commentedI just realized that this issue was closed with "works by design" status but being a feature request that doesn't work as described in the request it can't be closed with that status so I'll reopen it.
Comment #14
hass CreditAttribution: hass commentedSetting requested status
Comment #15
jrao CreditAttribution: jrao commentedWhy is this closed? Using php code inside text area is not recommended, for starters it won't be tracked by source control, and it can easily break the site. Plus the fact that this is just a one line change, I'm baffled why this is closed without explanation.
Comment #16
hass CreditAttribution: hass commented#9 is the answer.
Comment #17
jrao CreditAttribution: jrao commentedAlex's later reply showed #9 is not a good reason. Also per https://www.drupal.org/node/1203886, php module was removed from D8, and block module in D8 no longer uses php module, per #9 will you follow the core to remove it from D8 version of GA? You might as well start with D7 version...
Comment #18
hass CreditAttribution: hass commentedThis is a D7 issue. I'm not going to remove code in D7 and current D8 code still supports php module. If you can show me just one example in core that such an alter hook exists I'm fine with adding it.
Comment #19
hass CreditAttribution: hass commentedCode style is not acceptable.
Comment #20
jrao CreditAttribution: jrao commentedYeah, I'm not suggesting removing any code from any version, just adding a way to change visibility from code as a backup given now php module is on its way out. I'm not sure about the problem with the alter hook style, could you clarify what exactly is the issue here?
Comment #21
hass CreditAttribution: hass commentedThis is not core code style, has tabs. Show we first how you are able to alter block visibility with an alter hook and why the path based solution does not work, please.
Comment #22
jrao CreditAttribution: jrao commentedSo the style concern is just tab character in the patch? I think that should be easy to fix.
For alter block visibility via hook, Alex has showed it, see hook_block_list_alter, the example given there altered block visibility based on active language.
Path based solution doesn't always work, otherwise there wouldn't be the need for php module integration, right? This hook just provides an alternative to php module integration.
Comment #23
hass CreditAttribution: hass commentedI do not think
hook_block_list_alter
was made for what you try to abuse it here... :-)Comment #24
jrao CreditAttribution: jrao commentedHmmm, but the API document for hook_block_list_alter has an example of altering block visibility, I think it came from block.api.php, so this usage should be official?
Comment #25
hass CreditAttribution: hass commentedI just made php module green and created a working release as a side note.
Comment #26
dbl CreditAttribution: dbl commentedNeed this feature as well since we have certain other conditions except for pages and roles that determine if the user should be tracked or not. Is it something that will be added?
Comment #27
tduong CreditAttribution: tduong at MD Systems GmbH commentedUpdating this issue and closing #2733291: Add alter hook to _google_analytics_visibility_pages() as duplicate.
This is a reference to a concrete case: #2731279: Add google_analytics hook to skip default GA integration for AMP pages.
Comment #28
tduong CreditAttribution: tduong at MD Systems GmbH commentedUpdated check in
google_analytics.api.php
to have an more sensible example :)Added a test but not sure how to fix it. No google-analytics script is shown...
Comment #39
tduong CreditAttribution: tduong at MD Systems GmbH commentedTried to fix the test debugging some functions, if the debug statements are there the test passes, otherwise it fails. Looks like a caching problem... will figure it out after lunch.
Comment #45
stBorchertRe-roll against latest development version.
Comment #46
japerryWith the sunset of legacy google analytics, the 8.x-2.x module is now unsupported. If this is still an issue with the 4.x version, please file a new issue in the queue.