Base-template overrides break if nothing overridden

support
1

I have a site with a layouts/_default/baseof.html that looks like this:

<!DOCTYPE html>
<html lang='en-US'>
<head>
    <meta charset='UTF-8'>
    <title>
        {{ block "title" . }}
            {{- .Site.Title -}}
            {{ with .Title }} — {{ . }}{{- end -}}
        {{ end }}
    </title>
    <meta name='viewport' content='width=device-width, initial-scale=1'>
</head>
<body>
    <header>
        <h1><a href='/'>{{ .Site.Title }}</a></h1>
        {{ with .Title }}<span>—</span> <h2>{{ . | safeHTML }}</h2>{{ end }}
    </header>
    <main>
        {{ block "main" . }}
            <section>
                {{ .Content }}
            </section>
        {{ end }}
    </main>
</body>
</html>

and a layouts/index.html with nothing in it.

However, when I try to view http://localhost:1313/ it doesn’t show anything. If I put the following in layouts/index.html, everything works OK:

{{ define "nothing" }}{{end}}

When I tried to reproduce this behavior on the Playground, I couldn’t. html/template, as far as I can tell, isn’t causing this behavior.

Example: must-have-something.zip

2

So are you saying that a blank layouts/index.html renders absolutely nothing? And then only renders something if you include a define statement?

3

This is as designed. A base template can not live without a template using it, so to speak.

Note that the baseof.html naming convention etc. are purely a Hugo construct, and trying to reproduce in Go playground is impossible.

1 Like
4

@rdwatters correct.

@bep “a base template cannot live without a template using it” makes sense to me, which is why I created the empty layouts/index.html. However, for my purposes here, the base template was already just what I needed and there was nothing, in my mind, that needed overriding so I overrode nothing and got a surprising result. Having to “override” something that wasn’t there in the first place (there is no {{ block "nothing" . }} in baseof.html) isn’t intuitive or documented anywhere.

(in general, when I’m developing with Hugo I seem to get blank pages more often than I did with Jekyll and it’s not obvious to me where to start debugging beyond “reexamine your most recent changes”. I tried hugo serve -w --log --verboseLog when this particular blank-page error happened, but nothing useful showed up in stderr/stdout. One idea that might help is for Hugo to print out extended information every time it generates a blank page, but I’m not sure what sorts of information should go into this extended information dump.)

1 Like