For a long time now I have been setting the Web Property ID as blank via settings.php or similar methods so that tracking doesn't occur on any environment other than my production environment.

Recently I released a module, Contextual variables, that allows for variables defined by the Variable module to be defined via Context, allowing me to theoretically do what I used to do via settings.php via UI instead.

I was happy to see that the Google Analytics module had declared the Web Property ID, but unfortunately I found that it required a value and validated the value, which meant I couldn't set it to blank to prevent tracking to occur.

While I understand that this may not exactly be something you would want to encourage, it is something I would think would be extremely useful.

Patch attached in comment #1.

CommentFileSizeAuthor
#18 variable_empty_id-1964052-18.patch4.95 KBdeciphered
#15 variable_empty_id-1964052-15.patch3.26 KBdeciphered
#1 variable_empty_id-1964052-1.patch1.57 KBdeciphered

Comments

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Version: 7.x-2.x-dev » 7.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new variable_empty_id-1964052-1.patch1.57 KB
hass’s picture

hass commented
Status: Needs review » Closed (works as designed)

I suggest to set the value via drush in DEV. You need to change a lot of settings in dev and this is just one. We already have domain and i18n support. Not validating the UA code sounds like no option at all to me as this caused a LOT of support issues in past.

hass’s picture

hass commented
Status: Closed (works as designed) » Needs review

Hm... Should take a look to the patch first. Allowing an empty value sound useful to me, but removing validation completly not.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Hass,

This doesn't remove validation completely, what it does is not return false if the value is left empty, which as you say is useful. If the value is not empty, validation will work as normal.

Happy to modify the patch in anyway you see fit, but as it is I think it should satisfy all your potential concerns.

hass’s picture

hass commented
Version: 7.x-1.x-dev » 8.x-2.x-dev
hass’s picture

hass commented

#1: variable_empty_id-1964052-1.patch queued for re-testing.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

I get a feeling that the test isn't going to be processed :|

hass’s picture

hass commented
Version: 8.x-2.x-dev » 7.x-2.x-dev

Since variable module may not exists in D8 moving back to D7. But why are we only changing this on variables form and not also on admin form?

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

I'm happy to change this on the standard form as well, will update the patch as soon as I have a chance.

hass’s picture

hass commented
Status: Needs review » Needs work

Any news?

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Haven't had a chance yet, my priorities change from day to day based on the client work I am currently doing.

phily’s picture

phily
he/him
Primary language French
Location 🇪🇺🇫🇷 Paris, France
commented
Issue summary: View changes

Or use a fake ID like UA-1234567-89 (I hope it's fake ;-)

hass’s picture

hass commented

I typically use UA-1234-1 as it's used in references and docs. It allows a test.

hass’s picture

hass commented
Status: Needs work » Closed (won't fix)

No update for an extended period of time. Closing because of inactivity.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Closed (won't fix) » Needs review
StatusFileSize
new variable_empty_id-1964052-15.patch3.26 KB

Re-rolled and added change from #8.

The last submitted patch, 1: variable_empty_id-1964052-1.patch, failed testing.

The last submitted patch, 1: variable_empty_id-1964052-1.patch, failed testing.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
StatusFileSize
new variable_empty_id-1964052-18.patch4.95 KB

Re-roll

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Strike that last re-roll, forgot I'd already re-rolled :|

hass’s picture

hass commented
Status: Needs review » Needs work

Broken re-role

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Needs work » Needs review

The reroll is fine, it's just unnecessary as the previous patch is identical. Both apply and both work.

hass’s picture

hass commented
Status: Needs review » Needs work

Not identical. Review the patch, please.

hass’s picture

hass commented 
+++ b/googleanalytics.admin.inc
@@ -305,7 +304,7 @@ function googleanalytics_admin_settings_form($form_state) {
-    '#description' => t('You can set values for Google Analytics <a href="@custom_var_documentation">Custom Dimensions</a> here. You must have already configured your custom dimensions in the <a href="@setup_documentation">Google Analytics Management Interface</a>. You may use tokens. Global and user tokens are always available; on node pages, node tokens are also available. A dimension <em>value</em> is allowed to have a maximum length of 150 bytes. Expect longer values to get trimmed.', array('@custom_var_documentation' => 'https://developers.google.com/analytics/devguides/collection/analyticsjs/custom-dims-mets', '@setup_documentation' => 'https://support.google.com/analytics/answer/2709829')),
+    '#description' => t('You can set values for Google Analytics <a href="@custom_var_documentation">Custom Dimensions</a> here. You must have already configured your custom dimensions in the <a href="@setup_documentation">Google Analytics Management Interface</a>. You may use tokens. Global and user tokens are always available; on node pages, node tokens are also available. A dimension <em>value</em> is allowed to have a maximum lenght of 150 bytes. Expect longer values to get trimmed.', array('@custom_var_documentation' => 'https://developers.google.com/analytics/devguides/collection/analyticsjs/custom-dims-mets', '@setup_documentation' => 'https://support.google.com/analytics/answer/2709829')),

Fault

hass’s picture

hass commented
Status: Needs work » Closed (won't fix)

No update for an extended period of time. Closing because of inactivity.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Closed (won't fix) » Needs work

Reopening. There is at least one working patch in this issue as well as working code, it would be a shame to lose it due to confusion.

I will attempt a re-roll this evening.

hass’s picture

hass commented
Version: 7.x-2.x-dev » 8.x-2.x-dev
deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

@hass Am I correct in your changing of branch to imply that you want the work done to 8.x-2.x before backporting to 7.x-2.x? If so, it may take longer as it's no longer a simple re-roll, however if that is the desired process I have no issue with that as I will be implementing the same workflow in my modules soon enough.

hass’s picture

hass commented

Yes, GA D8 is ready for prime time. You can rerole, but it also requires a D8 patch first.

Additionally I'm still not sure how we can solve the usability issue. I'd like to have form validation and show the red star to imply this is a must value. If I only think about the number of issues we had before I introduced the validation/requirement compared to today I'm still not convinced this helps users except for edge cases. I wish we could do some comparison to core or other modules how they handle such form settings.

It is sooo easy to delete this variable via drush...

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Ok, so maybe we can re-think this, my needs are to suppress Google Analytics when in specific environments, and while this solution works perfectly, if you are not happy with the approach then it's going to cost me more time than I have.

Instead, how about an 'enabled' variable of some sort, or a hook_suppress() approach (preferably in conjunction with a variable).

Thoughts?

As far as the 'delete via drush' approach, that is too reliant on human interaction for my likes, I prefer to keep things as automated as possible.

hass’s picture

hass commented

I always put the drush commands in a script. This easily allows me to backup live systems, restore them scripted on test/staging and then run a bunch of drush commands to correct all variables that need to be changed to the system.

These are at least:

drush vset file_private_path C:/hiddenpath/foo
drush vset file_directory_temp C:/xampp/tmp
drush vdel googleanalytics_account
drush vdel piwik_site_id

How do you change the paths from production to dev without drush?

I do not like to waste both of our time, but I think we lose more than we win. At least 1-2 useless support cases per week is what I will get here.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

I use the Contextual variables module that I wrote which allows any variable that's been exposed to the Variables module to be modified/set as a Context reaction, in conjunction with other modules that determine what environment I am currently in.

japerry’s picture

japerry
Location KOMK
commented
Status: Needs work » 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.