I see a regression in Hugo 0.42 (verified that this error wasn’t on 0.41). And this is without using the theme composition feature.
Gitlab is down ATM, so cannot point to the repo yet … but here are some details.
The first build of hugo server is fine:
| EN
+------------------+-----+
Pages | 777
Paginator pages | 18
Non-page files | 15
Static files | 187
Processed images | 0
Aliases | 6
Sitemaps | 1
Cleaned | 0
Total in 1985 ms
Watching for changes in /home/kmodi/hugo/scripter.co/{content,data,layouts,static,themes}
Watching for config changes in /home/kmodi/hugo/scripter.co/config.toml
Watching for config changes in /home/kmodi/hugo/scripter.co/themes/refined/config.toml
Serving pages from memory
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop
But when I change a content file, I get:
Change detected, rebuilding site
2018-06-12 12:38:05.386 -0400
Source changed "/home/kmodi/hugo/scripter.co/content/posts/time-formatting-in-go/index.md": WRITE
ERROR 2018/06/12 12:38:05 Failed to render "_default/list.html": runtime error: invalid memory address or nil pointer dereference
Total in 767 ms
ERROR 2018/06/12 12:38:06 Failed to rebuild site: logged 1 error(s)
Interestingly, even though it says Failed to rebuild site: logged 1 error(s), the site rebuilds fine… I think … because the page live reloads with new content.
Here’s the relevant snippet from my _default/list.html:
{{ range .Pages.GroupByDate "2006" }}
<h2 id="{{ .Key }}">{{ .Key }}</h2>
<ul class="no-bullets">
{{ range .Pages }}
{{ .Render "li" }}
{{ end }}
</ul>
{{ end }}
If I remove the {{ .Render "li" }} line, the error goes away.
But my _default/li.html is this… could something in there break in 0.42?:
<li class="h-entry li">
{{ partial "date-maybe.html" (dict "page" . "fmt" "01/02" "fmtupd" "2006/01/02") }}
<span class="p-name post-title no-text-decoration"><a class="u-url" href='{{ .Permalink }}'>{{ .Title }}</a></span>
<div class="right">
{{ partial "taxo-buttons.html" . }}
</div>
<div class="clear-float"></div>
</li>
I thought so… but emptying the li.html still gives that error!