Environment variable names with underscores

support
1

Hi all,

I have an issue setting environment variables on compile if the parameter name has an underscore in it.
I’m trying to set the variable called api_key under a section called map in a config file called params.toml. I have verified that I can set another parameter called zoom under the same section with the following command:

env HUGO_PARAMS_MAP_zoom="15" hugo

But trying the same with api_key fails. I’m guessing it’s to do with the underscore in the parameter name. I’ve tried to wrap api_key in brackets, single and double quotation marks and I’ve tried to escape the underscore api\_key. Nothing works. Anyone knows how to do this?

I’m running Hugo v0.74.3

Christian

2

This appears to be a limitation imposed by viper.

Workaround:

HUGO_PARAMS_MAP='{ "api_key": "abc" }' hugo

But, this overrides everything under MAP, not just api_key. So, if your config.toml looks like this:

[params.map]
api_key = "default value of map.api_key"
foo = "default value of map.foo"

The value of foo will be nil. To avoid this you would have to set both:

HUGO_PARAMS_MAP='{ "api_key": "abc", "foo": "bar" }' hugo server

Reference: https://github.com/gohugoio/hugo/issues/5601

3

I see. Your workaround works for me. Thank you:)

4

Okay! Was a little fast.

Your method does indeed inject the correct parameters into the configuration. If I look at the config after injection using the following command

HUGO_PARAMS_MAP='{"engine":"1","api_key":"12345","zoom":"15"}' hugo config | grep -I params

I do get map[engine:1 api_key:12345 zoom:15], but for some reason the map breaks if I compile using hugo server or hugo. The map is completely gone, frame and all. The space for the map is still allocated in the html, but it’s just blank.

5

Try this:

git clone --single-branch -b hugo-forum-topic-28715 https://github.com/jmooring/hugo-testing hugo-forum-topic-28715
cd hugo-forum-topic-28715
HUGO_PARAMS_MAP='{"engine":"1","api_key":"12345","zoom":"15"}' hugo server

At a minimum, you must define an empty params.map in config.toml.

6

I added a similar test post to my site and it looks like the parameter does indeed work.

Screen Shot 2020-10-09 at 2.44.34 PM
Screen Shot 2020-10-09 at 2.44.34 PM1704×1020 83.3 KB

So that part works:) Now, these three parameters define a embedded google map, which doesn’t show up when I inject the parameters. It must be a problem with the theme I use (Wowchemy) I guess. But it’s just strange that this parameter injection into the configuration changes something outside the config file!

Site without injection:

Screen Shot 2020-10-09 at 2.49.22 PM
Screen Shot 2020-10-09 at 2.49.22 PM2440×1310 596 KB

Site with injection:

Screen Shot 2020-10-09 at 2.48.58 PM
Screen Shot 2020-10-09 at 2.48.58 PM2428×1476 136 KB

These three parameters already exist in the configuration, so it’s not like I’m creating new parameters.

./config/_default/params.toml

[map]
  # To show your address on a map in the Contact widget, enter your latitude and longitude (above)
  # and choose a map provider below.
  #
  # To use Google Maps, set `engine` to 1 and enter your API key that can be obtained here:
  #   https://developers.google.com/maps/documentation/javascript/get-api-key
  # To use OpenStreetMap tiles, set `engine` to 2.
  # To use OpenStreetMap on a high traffic site, set `engine` to 3 and enter your API key that can be obtained here:
  #   https://www.mapbox.com/studio/account/tokens
  #
  # Map provider:
  #   0: No map
  #   1: Google Maps
  #   2: OpenStreetMap (Mapnik)
  #   3: OpenStreetMap (Mapbox)
  engine = 1
  api_key = ""
  zoom = 15
7

You are injecting three strings. I think you want to inject one string and two integers.

HUGO_PARAMS_MAP='{"engine":1,"api_key":"12345","zoom":15}' hugo server

With this, map.engine and map.zoom will be float64. When you set them in params.toml, the type is int64, so this may not work. You might have to cast them to int within the theme.

8

Right! Nice catch, thanks:)

Stupid question, but how would I go about recasting to int64? standard go would just be to call {{ int64() }}, but that doesn’t work. Or maybe I’m doing it wrong.

9

First, have you tested to see if leaving the values as float64 works?

If not, use int.

10

It might! Recasting into int, doesn’t work. But I don’t think that’s the problem. I’ll investigate further and return.

11

I’ve been digging further and found that a lot of the Java Scripts needed for my site aren’t loaded when I inject parameters in the configuration. I’ll be honest, I have no idea why only a subset of the defined JS would ever be loaded, or what could coarse it.

I’ve attached a screen dump from the JS console:

JSload
JSload1325×1412 426 KB

12

Please post a link to the public repository for your project.

13

Github:

I’m running v4.8.0

14

This is not what I asked for.

15

Sorry, about that!

Here the link:

16

Yes, it does.

See:
https://github.com/wowchemy/wowchemy-hugo-modules/blob/d8367bbe52245885028f6e5a7b8fa01459453c86/layouts/partials/site_js.html#L29

{{ if eq site.Params.map.engine 1 }}

When engine is read from params.toml, its type is int64.
When engine is injected on the command line, its type is float64.

An equality comparison between the two types will always be false. For example:

{{- if eq 1 1.0 -}}
  TRUE
{{- else -}}
  FALSE
{{- end -}}

yields FALSE.

To fix this, change the comparison to:

{{ if eq (int site.Params.map.engine) 1 }}

and run:

HUGO_PARAMS_MAP='{"engine":1,"api_key":"your-api-key","zoom":15}' hugo server

You might wish to raise an issue here:
https://github.com/wowchemy/wowchemy-hugo-modules/issues

17

Nice catch!:slight_smile: Your fix totally did the job.

I was testing the int64 vs float64 here:

Somehow it’s not an issue here. Leaving it as is, still works after fixing the if statement in site_js.thml.

I’ll raise an issue for a fix. Other people will have the same problem is they configure the search engine.

I can’t thank you enough for all your great help :+1: :star_struck:

18

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.