Use integer variables from front matter .Params

[galaktor]

I'm relatively new to Hugo, so I could be doing something wrong...but here goes.

It seems like I cannot use numerical (i.e. integer) values from my front matter params. I wanted to set a number in there and use it as an argument for the "first" function i.e.

+++
foo = 10

range first .Params.foo .Data.Pages

I couldn't debug this properly but from what I saw using some "printf debugging" via the template, the foo variable was a string and first didn't like that.

Any way to cast or use number variables?

Thanks

[tatsushid]

Did you use toml as your front matter, didn't you? I tested toml decoding behavior with a following small code

package main

import (
        "fmt"
        "os"

        "github.com/BurntSushi/toml"
)

func main() {
        tomlStr := `foo = 10`
        var data map[string]interface{}
        if _, err := toml.Decode(tomlStr, &data); err != nil {
                fmt.Fprintln(os.Stderr, err)
                os.Exit(1)
        }
        fmt.Printf("%#v\n", data)
        if data["foo"] != 10 {
                fmt.Println("foo isn't int(10)")
        }
        if data["foo"] != int64(10) {
                fmt.Println("foo isn't int64(10)")
        }
}

It shows 10 is int64 type, not int type. Hugo does as same as above so I think .Param.foo would be int64(10) and it causes the problem you mentioned because first function expects int as its first parameter.

If this is true, one of the workarounds is using YAML as the front matter. YAML library used in Hugo converts 10 to int(10), not to int64(10) and to solve the problem fundamentally, it is needed to change that first function accepts any int family value as its first parameter.

[galaktor]

Thanks for that. I can confirm that it works when I use YAML front matter format. So would be great to support that consistently in the others as well!

[galaktor]

btw same issue seems to exist for .Site.Params defined within config.toml

[bep]

I cooked a patch fro the First-function, but as there may be more cases (now and in the future), this should maybe be solved by getting the sources in line, either by changing the libraries (not realistic) or create an adapter of kind (should be possible).

The template API have a limited usage scope, but the interface{} type API for simple integer types looks kind of ... not so pretty.

[galaktor]

I see the same issue when using the result of "len" as an arg in "gt"

 {{ if gt (len .Params.somelist) 0 }}

where somelist is defined in a TOML front matter

somelist = [ "foo" ]

it seems to work output-wise, but I see this error from hugo

ERROR: 2014/10/12 Rendering error: reflect: call of reflect.Value.Type on zero Value

[bep]

@galaktor My guess your last sample is something different. As it works "output-wise" my best guess is that you have somelist defined in some of the pages, but not all. It's likely the len-function that fails for nil-arguments. In Hugo-world len(nil) should probably be 0 and not return an error.

[galaktor]

Cheers @bjornerik that was it. Hard to figure these out sometimes :-)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.