Add css class depending on layout / type

I try to add a css-class to the body element depending on the layout of the entry. Use case is, that I specify the layout in the markdown front matter like

layout: "foo"

foo.html includes a generic partial for the header and in the header I would like the body element to be like

<body class="foo">

The suggested sollution in the forum is

<body{{ with .Params.layout }} class="{{ . }}" {{ end }}>

But layout is not a param. According to the printf-debug it is somehow passed to the template but I cannot access it.

Layout is an attribute on Page, so try:

{{ with .Layout }} class="{{ . }}" {{ end }}

Thanks! I got confused (again) with the case-conversion of different params. Also because in the debug output it is lower case.
But unfortunately, .Layout renders into the array of actual template candidates :slight_smile:
(The output is something like class="[dir1/foo.html _default/foo.html]")

You are correct, you cannot use Layout for this. Maybe Type – or a customer param?

All methods and attributes on Go objects (Page, Node etc.) start with an upper case character – this is how you export / make stuff public in Go. This is not a restriction in Go maps (.Params is a map).

The custom param was the more unelegant solution I already tried (works, but duplicate code). I was hoping, that I missed some easy thing, because in the output of

{{ printf "%#v" . }}

I can see “layout” with the desired value as a member of a map on the same level like Params, Content, renderable, frontmatter and so on.

What you see is the private field “layout” (i.e. not a member of a map) – not sure how printf gets access to it (reflection?).

OK, thanks for pointing that out for me!
I worked around it and went the “type” - path.

In case, someone else has the same problem:
I reorganized my templates from layouts/_default/foo.html to layouts/foo/single.html and use type instead of layout in front matter now. This way I can use .Type in the body - element:

<body{{ with .Type }} class="{{ . }}" {{ end }}>

And I guess he who named this field and method didn’t really think too hard about, so I created this issue: