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