How to Exclude Google Analytics When Running Under Hugo Local Server

Perhaps I have totally misunderstood!

Say we have 1 VPS, 2 domains (site.com, dev.site.com).

site.com pulls from master.
dev.site.com pulls from testing.

If we do export HUGO_ENV=production it will then conflict with the dev.site.com testing branch, which expects the HUGO_ENV= testing.

Since there can be only one HUGO_ENV (per user on the server), either you’d have to create more users, or you’d have to buy another server.

Unless I have totally misunderstood something. I might have.

the environment variable is specific to the instance of Hugo you are running, not a user.

Just to be clear @Hash_Borgir when you run Hugo, you run the environment variable before the Hugo command, so this…

in full is,
HUGO_ENV="production" hugo

And HUGO_ENV can be anything, for example: `HUGO_ENV=“testing”

If you run nothing, then the test for the environment variable being “production” is false.

I sometimes put this in my body tag to I make sure I know which environment I have set: {{ with getenv "HUGO_ENV" }} {{ . }}{{ end }}

Hope that’s helpful!

I have no idea how else to say it. It seems that you don’t yet understand the problem. Pondering it over further.

Can HUGO_ENV be both “testing” and “production” at the same time? On the same server, under the same user? …

I’ll repeat again, should it help.

There is 1 server. It hosts 2 domains.

The server is my “production server”, so I would naturally login, and do export HUGO_ENV=“production”.

{{ if eq (getenv “HUGO_ENV”) “production” }} do stuff {{end }}

Then I build my site with this code. Since the ENV VAR has been set to production, it will build with analytics. site.com

Now, this server also houses test.site.com (testing branch).

So, when you biuld the dev.site.com from a testing branch in a diff doc_root, since ENV VAR is “production” it will still build with Analytics.

So, if you set export HUGO_ENV=“testing”, it will build without analytics for dev.site.com.

If you now try to build your site.com it expects “production”, it finds “testing” and builds without analytics.

I hope that helps to understand further the problem w/ this approach on a single server.

One could have two users on the machine.

hugoprod, and hugotest.

login as hugoprod and export HUGO_ENV="produciton"
login as hugotest and export HUGO_ENV=“testing”

hugoprod pulls from master
hugotest pulls from testing

Each user now has their correct env variable set.

What you suggest ONLY works for a single user on a single server.

It’s a method different than using a JS check, but it fails on multienv. systems.

Env. is one. You can’t have multiple values for the same ENV VAR under the same user. One env. One value. That’s how it works.

I think you’re thinking of server environments. I’m speaking specifically of a command you can run with your Hugo build. It has nothing to do with servers or users.

I edited my post. Please refer again. Also, hugo runs in an env. in a server, under a user. That’s how posix systems fucntion for the most part.

Thanks, I hope your posts help someone who has that scenario to deal with.

1 Like

Oh, yes, sir. I hope so too. This led me on a merry hunt for a good little while! I never thought to put the env variables in my build scripts. It happens.

I hope I was able to explain clearly enough. English is not my first language.

For windows users. HUGO_ENV=“produciton” need to do so:

set HUGO_ENV=produciton
hugo server
1 Like

Using environment variables in code may not an advisable approach for those building following Twelve-Factor App principals, which state about config:

Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.

As an alternative consider instead passing config to app via hugo bin flags at build time, a common approach seen in the PHP and Ruby web development communities.

I’m only posting this for anyone (like me) who can’t be bothered setting up environment variables to exclude Google Analytics.

uBlock (and other ad-blockers) blocks Google Analytics by default.

Or if you’re against using ad blockers Google offers the Google Analytics opt-out extension

https://tools.google.com/dlpage/gaoptout

Both solutions work when hugo server is running.

I didn’t suggest setting the environment in config.

My post is mostly advisory for others. Getting the job done is step one. I did see a snippet above where env vars were being embedded in code (and not config), which is why I dropped the 411. Of course practicality usually trumps ideal design in my book any day. No harm no foul.

Thank you! your response helped me a lot!

If you use an environment config I suggest not using environment names—they do not scale cleanly. Instead, a more flexible and scalable approach is to create an envrionment-based config file such as config.dev.toml, set the googleAnalytics config to the empty string (to disable it) and point to the environment config via CLI flag when running hugo commands.

1 Like

My website is not an app, 12-factor or otherwise. :slight_smile:

I am noting that so other folks don’t see the link and presume that is a best practice. It is a practice following a particular methodology. :upside_down_face:

Hugo is an App. What it produces is a Website. And the App which generates a Hugo site—be it yours your someone else’s—will not scale cleanly using environment-based config in the template files for the reasons I indicated above, and based on 10 years of enterprise development experience.

Stumbled on this thread after having the same problem and just read through this - is there any downside to making a PR to Hugo to replicate the Disqus logic in the GA template? I’ve got the code working locally and it’s building on an existing pattern.

Hello, I guess this is the prefered way now @DarwinJS

<!-- Pour Google Analytics sauf mode dev server -->
{{- if not .Site.IsServer -}}
  {{ template "_internal/google_analytics.html" . }}
{{- end -}}
5 Likes

That’s definitely cleaner than using branch logic with environment names. A bit on the clever side, but will save those who don’t want to or are too lazy to use environment-specific config files.