Aren't all front-matter parameters lower-cased internally?

support
1

Continuing the discussion from Disable specific content types:

I am curious to know the cases where front-matter params can be read back in non-lowercase form e.g. .Params.camelCase.

2

I often use camelCasing for front matter params, but .Params.camelcase will work just as .Params.camelCase.

My initial thought was that Hugo lowercase whatever .Params’s key is used in the template before fetching its value.

3

Just to clarify, if the front-matter has camelCase, I can access it as .Params.camelcase, but not as .Params.camelCase. I just tested that for this case.

Are you saying the latter works for you? Do you have a sample I can look at to understand?

Also, what I said is very evident when using the debugprint partial… All camelCase front-matter keys show up in all-lowercase in the debugprint output.

Update: This is confusing… I can now refer a camelCase param as .Params.camelCase is another test…

4

OK, I finally have a test case… with a crazy conclusion.

If we do:

{{ with $page_handle }}
    {{ .Params.camelCase }}
{{ end }}

it works, interestingly even .Params.camelcase and .Params.CamelCase work (looks like the param can be fetched case-insensitively), but …

If we try to do:

{{ $page_handle.Params.camelCase }}

it does not work!.. only {{ $page_handle.Params.camelcase }} will work (note that here that param key is in all lower case).

So it further strengthens my rule-of-thumb: Always have the front-matter keys in all-lowercase.

5

You are right about the lower-case recommendation. It may be sensible to stick with “my_param” format… But

The thing is, we got lots of questions/issues related to this at some point, so I wrote an AST template transformer … To lower case

And even if I know about 1 case where it fails (there is an issue about it), your examples are surprising, and if you are correct, then they are bugs and should be fixed.