Caddy: Numeric markdown metadata can't be used in template

Created on 27 Nov 2016 · 8Comments · Source: caddyserver/caddy

Numeric values in markdown metadata becomes "<no value>" in template.

template:

<!DOCTYPE html>
<html>
    <head><title></title></head>
    <body>
        ...
        <input name="test" value="{{.Doc.number1}}">
        <input name="test" value="{{.Doc.number2}}">
        ...
    </body>
</html>

markdown:

---
number1: 5
number2: "5"
---

Output:

<!DOCTYPE html>
<html>
    <head><title></title></head>
    <body>
        ...
        <input name="test" value="<no value>">
        <input name="test" value="5">
        ...
    </body>
</html>

Expected Output:

<!DOCTYPE html>
<html>
    <head><title></title></head>
    <body>
        ...
        <input name="test" value="5">
        <input name="test" value="5">
        ...
    </body>
</html>

Tested with Caddy 0.9.3.

help wanted

Source

cork

Most helpful comment

It will now work for floats too ;)

wendigo on 29 Nov 2016

😄1 👍1

All 8 comments

You're right @cork - there's type assertion in https://github.com/mholt/caddy/blob/master/caddyhttp/markdown/metadata/metadata.go#L67

Providing fix in a couple of minutes

wendigo on 29 Nov 2016

Here you go: https://github.com/mholt/caddy/pull/1278

wendigo on 29 Nov 2016

It will now work for floats too ;)

wendigo on 29 Nov 2016

😄1 👍1

Why do we even need to do the conversion, again? I haven't looked at this code in a long time, but I feel like having to enumerate every possible type is impractical. (Maybe not for 99% of uses, but still...)

mholt on 30 Nov 2016

@mholt It's due to automatic type detection/conversion made in the yaml decoder: something: number and something: 1234 will be decoded to string : string and string : int when decoding into map[string]interface{}. I'm fine with the change I made - it works for YAML, TOML and JSON files.

wendigo on 30 Nov 2016

I find myself agreeing with @mholt on this. Could the markdown not simply specify that it can only be a string. Non enclosed values are simply not allowed?

tobya on 30 Nov 2016

@wendigo I like your change too, I'm just wondering if we can improve it a little more by making it kind of agnostic of the type. :) (If not, I'll merge your change anyway, but I just thought I'd ask while we had it out.)

mholt on 30 Nov 2016

@mholt: sure, check it now - now it's type agnostic :)

wendigo on 30 Nov 2016

👍1

Was this page helpful?

0 / 5 - 0 ratings