Thanks, I hope your posts help someone who has that scenario to deal with.
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
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
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.
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
My website is not an app, 12-factor or otherwise.
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.
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.