Looks like nothing criminal is going on here, at least nothing that would warrant a nil pointer dereference. Also, 0.92.0 release notes say nothing about changes in .Page.RenderString, so I’m guessing this is a side-effect of the whole .Page rework — and a regression. Right?
I can’t share the whole project (for several reasons), but I can share a part that reproduces the issue. This archive contains config, a couple of pages and a snapshot of the theme; trying to build it with 0.92.0 results in the cryptic error, while 0.91.2 builds ok.
If I replace your version of the loveit theme with the current version f787a4e there are no errors.
In layouts/index.json, the current version of the loveit theme ranges through .Site.RegularPages.
Your version of the loveit theme does something different. If I revert that one line, the site builds without errors.
If the diff below, a/layouts/index.json is from the current version of the loveit theme, while b/layouts/index.json is from your version of the loveit theme.
This is very interesting, because it works on the one-page-of-content little piece here, but the whole site (same theme, thousands of content pages) fails — with the same error as before.
Still, whatever breaks .Page.RenderString here seems to be introduced by the pageset/reg-pages-all.html partial, and particularly by the piece of logic that can be stripped down to this:
{{- $pages := .Site.RegularPages -}}
{{- range .Site.Home.Translations -}}
{{- $pages = $pages | union .Site.RegularPages -}}
{{- end -}}
{{- return $pages -}}
This piece of logic is called as a drop-in replacement for .Site.RegularPages in several places in my modification of the theme.
I think I’ll try to strip the mvp of even more things that don’t affect this issue when I have time. Hopefully it will help to isolate the underlying bug one way or the other.