About latest hugo's quoteless strings

[anonlyuriew]

I’m confused about the latest hugo update. how easy is it to convert the old quoteless values into anchors and aliases, and how if i get it so?

[jmooring]

I don’t understand your question.

[irkode]

mm, these are two different topics:

anchors and aliases

this is a new feature and provides the ability to reuse a defined block (anchor) at a second position (alias) in the yaml file.

Nothing to adapt/migrate if you don’t want to use that feature.

quoteless values

this is a change how values in a yaml file are treated in the resulting variables

given that with unquoted strings ON/OFF

params:
  testVerbose:
    verboseON: ON
    verboseOFF: OFF

testing that using 151 and 152 will show the difference

{{ warnf "\n%s" (debug.Dump site.Params.testVerbose) }}
{{ range $k, $v := site.Params.testVerbose }}
  {{ warnf "%s -> %T(%v) : {{ if %s }} returns %v" $k $v $v $k (cond $v "TRUE" "FALSE")}}
{{ end }}

OLD result

when reading that in these are converted to booleans.

{
  "verboseoff": false,
  "verboseon": true,
}
WARN  verboseoff -> bool(false) : {{ if verboseoff }} returns FALSE
WARN  verboseon -> bool(true) : {{ if verboseon }} returns TRUE

new result with 152+

these are treated as literal strings

WARN  {
  "verboseoff": "OFF",
  "verboseon": "ON"
}
WARN  verboseoff -> string(OFF) : {{ if verboseoff }} returns TRUE
WARN  verboseon -> string(ON) : {{ if verboseon }} returns TRUE

summarized:

If you curretly use the listed unquoted strings in your yaml file you will have to adjust conditionals/output using these values.

guess most problems here are with the falsy values because simple calling if $value will now be true for OFF, YES, … cause a non emkpty string is truthy. You never get false there

Migration path:

• if they are ment to be booleans → change their values to true and false (no quoting)
• if not mmh, you’ll have to check what you do with this, cause they have been

[anonlyuriew]

irkode seems to get it, but in very short, and to see if i got it right, if my YAML variables are booleans, then they’re supposed to be just true or false, and if not, then i’m going to change the quoteless strings the devs changed into booleans using newly written functions by me that override their default values, right?

[irkode]

@anonlyuriew

if not, then i’m going to change the quoteless strings the devs changed into booleans using newly written functions by me that override their default values,

this time it’s me to be lost in space

if you have a property NAME: OFF you have to check all places in your layouts and params shortcodes in md files where you access the value.

• if you treat it as a boolean in your code change it to NAME: false

you cannot “override” the value set in the yaml file with a custom function. you have to adapt the code that uses the properties to handle.

do this code check for all properties that use the listed values.

[anonlyuriew]

well, that pretty much cleared things up for me.

thanks!