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?

CommentFileSizeAuthor
#45 google_analytics-switch_visibility_setting-1813014-45.patch3.43 KBstBorchert
#45 interdiff-1813014-39-45.txt1.42 KBstBorchert
#39 dynamically_switch_visibility_setting-1813014-39-DEBUG.patch4.45 KBtduong
#39 dynamically_switch_visibility_setting-1813014-39.patch3.83 KBtduong
#39 interdiff-1813014-28-39.txt1.63 KBtduong
#28 dynamically_switch_visibility_setting-1813014-28.patch3.65 KBtduong
#28 dynamically_switch_visibility_setting-1813014-28-test_only.patch2.42 KBtduong
#28 interdiff-1813014-27-28.txt2.43 KBtduong
#27 dynamically_switch_visibility_setting-1813014-27.patch1.25 KBtduong
#1 dynamically_switch_visibility_setting-1813014-1.patch443 bytesAlex Savin
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alex Savin’s picture

A very simple patch for this.

Alex Savin’s picture

Status: Active » Needs review
hass’s picture

Why is there a need to change it dynamically? Paths can be configured statically.

hass’s picture

Status: Needs review » Closed (works as designed)

We already have this dynamic $page_match = php_eval($setting_pages);. You can use PHP code.

hass’s picture

Alex Savin’s picture

I 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.

hass’s picture

The 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?

Alex Savin’s picture

I 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).

hass’s picture

The 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?

Alex Savin’s picture

Yes 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.

Alex Savin’s picture

And 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.

Alex Savin’s picture

I 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.

Alex Savin’s picture

Status: Closed (works as designed) » Active

I 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.

hass’s picture

Status: Active » Closed (won't fix)

Setting requested status

jrao’s picture

Issue summary: View changes
Status: Closed (won't fix) » Needs review

Why 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.

hass’s picture

Status: Needs review » Closed (won't fix)

#9 is the answer.

jrao’s picture

Status: Closed (won't fix) » Needs review

Alex'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...

hass’s picture

This 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.

hass’s picture

Status: Needs review » Needs work

Code style is not acceptable.

jrao’s picture

Yeah, 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?

hass’s picture

Version: 7.x-1.x-dev » 8.x-2.x-dev
Issue tags: +Needs tests

This 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.

jrao’s picture

So 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.

hass’s picture

I do not think hook_block_list_alter was made for what you try to abuse it here... :-)

jrao’s picture

Hmmm, 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?

hass’s picture

I just made php module green and created a working release as a side note.

dbl’s picture

Need 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?

Status: Needs review » Needs work

The last submitted patch, 28: dynamically_switch_visibility_setting-1813014-28.patch, failed testing.

The last submitted patch, 28: dynamically_switch_visibility_setting-1813014-28.patch, failed testing.

The last submitted patch, 28: dynamically_switch_visibility_setting-1813014-28.patch, failed testing.

The last submitted patch, 28: dynamically_switch_visibility_setting-1813014-28.patch, failed testing.

The last submitted patch, 28: dynamically_switch_visibility_setting-1813014-28.patch, failed testing.

The last submitted patch, 39: dynamically_switch_visibility_setting-1813014-39.patch, failed testing.

The last submitted patch, 39: dynamically_switch_visibility_setting-1813014-39.patch, failed testing.

The last submitted patch, 39: dynamically_switch_visibility_setting-1813014-39.patch, failed testing.

The last submitted patch, 39: dynamically_switch_visibility_setting-1813014-39.patch, failed testing.

The last submitted patch, 39: dynamically_switch_visibility_setting-1813014-39.patch, failed testing.

stBorchert’s picture

japerry’s picture

Status: Needs review » Closed (outdated)

With 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.