Too little information about template problems

[phippg]

Today I was porting an existing theme over to use with Hugo, and when I was finished, or so I thought, and tried to compile I get an error stating ERROR: 2014/06/02 Rendering error: html/template: "theme/_default/single.html" is an incomplete template.

I am sorry, but this doesn't help me in any way; is this a default by the Golang templating? Because if not, I would love to know where exactly the error occured, so I could at least narrow it down.

[phippg]

hugo check gives me the following result:

first.md (renderer: markdown) (layout: post/single.html, exists: false) (layout: single.html, exists: false)
 canonical => /home/welloy/blog/build/post/first/index.html

[spf13]

Try running with verbose on (-v). It should tell you more.

[spf13]

To be clear run the normal hugo or hugo server with -v, not hugo check.

[phippg]

I ran it with verbose on, but to I needed the information in regards to the layouts under a theme directory. I ran hugo -v --theme=casper which produced the following (unfortunately not helpful to me):

INFO: 2014/06/02 Using config file: /home/welloy/blog/config.toml
INFO: 2014/06/02 syncing from /home/welloy/blog/themes/casper/static/ to /home/welloy/blog/build/
INFO: 2014/06/02 syncing from /home/welloy/blog/static/ to /home/welloy/blog/build/
INFO: 2014/06/02 found taxonomies: map[string]string{"tag":"tags", "category":"categories"}
ERROR: 2014/06/02 Rendering error: html/template: "theme/_default/single.html" is an incomplete template

Maybe I got something wrong in the directory structure, but afaik that error get's thrown when there is a problem in the templating in regards to single/double quotes and {{ template "partial/something.html" . }}

[phippg]

Okay, I guess I made some progress. Seems not having a _default/list.html turned out to be the problem. On another note I now get Rendering error: html/template:theme/_default/list.html:12: no such template "partials/footer.html" which is odd since I reference that partial in other locations.

[phippg]

After some more investigation I found some leftover curly braces which would explain the problem that any of the layouts were incomplete. I am still looking into the weird issue that the files seemingly can't access the partials (which are clearly there).

[phippg]

But wait! There's more! I copied my partials from the theme folder (root/themes/casper/layouts/partials) to root/layouts/partials and now the partials are presumably correctly detected and rendered.

Is that a design choice or simply due to the unfinished nature of theme support? In the example themes provided in your repositories the partial folders are nested inside the themes folder.

Nevermind, continuously writing down my findings led me to the correct way of using partials in themes.

[spf13]

Thanks for sticking with this @PhilG. As you concluded these were design decisions. I feel like the theme engine is complete, but lacking good user feedback because it is so new. This feedback is very helpful!

I'm considering making partials a standard for the next version where it would work in a similar way to the other templates with relative includes that check the /root/layouts/ directory prior to the /root/themes/casper/layouts/ directory.

Would that be better in your opinion?

[phippg]

Sorry for being a little late here!

I guess what you suggested would be the preferred way of doing it. Basically allow a manual override for partials (just as for all other theme related files) in /root/layouts/partials and if there is none check the /root/themes/theme-x/

[spf13]

This is now in master/HEAD

Steve Francia http://stevefrancia.com http://spf13.com http://twitter.com/spf13

On Wed, Jun 25, 2014 at 4:37 AM, PhilG notifications@github.com wrote:

Sorry for being a little late here!

I guess what you suggested would be the preferred way of doing it. Basically allow a manual override for partials (just as for all other theme related files) in /root/layouts/partials and if there is none check the /root/themes/theme-x/

— Reply to this email directly or view it on GitHub https://github.com/spf13/hugo/issues/316#issuecomment-47074563.

[aanomm]

Can I ask how the Hugo/Git relationship works? I'm still learning Github: I had in my head that Master branches were the latest stable release, but the docs for Hugo point to the releases page where v0.11.x is the latest downloadable version. So does that make the current Master branch for Hugo the next-to-be-released version? Or should I be using the current master version instead of v0.11?

What got me to asking is the new partials logic that @PhilG and @spf13 are speaking of above [checking layouts/partials before themes/partials] which is "now in Master/head". I'm using v0.11.x, so how do I include a partial which is located in the theme partials folder?

[anthonyfok]

I began experimenting with converting a Jekyll theme to Hugo some days ago, and ran into these terse html/template: "somefile.html" is an incomplete template error messages too, and wished that they could be more informative.

My preliminary (but possibly inaccurate) investigation: The is an incomplete template error comes out straight from the Go "text/template" or "html/template" library's executeTemplate(), and that is all Hugo receives from that upstream library.

That said, it seems when using a construct like tmpl, err := template.New().Parse(), the Go template library would be happy to diverge the exact error, say, an attempt to use an undefined variable.

If that is indeed the case, I recommend we do the following: Whenever executeTemplate() returns an error, we could do an extra Parse() for the sake of extracting the detailed error message from the Go template engine.

This is also a little reminder that I should probably add some tips on troubleshooting the incomplete template error, especially when a Jekyll theme template being converted is full of Liquid templating engine markups constructs, which obviously the Go template engine would not parse. The trick I found is to work from the top convert one (or a small set of) Liquid markup to Go template markup at a time, and use {{/* and */}} to comment out the rest of the file, etc. Working in this piecemeal fashion makes it easier to debug problems. :-)

[anthonyfok]

A follow-up to my last post, as I wasn't entirely correct.

1. Hugo already runs tmpl, err := template.New().Parse(), which is a prerequisite to running executeTemplate().
2. Hugo already tries to collect the err from the template.New(name).Parse(tpl) run in a call that looks like this: t.errors = append(t.errors, &templateErr{name: name, err: err}). It seems to be collecting all the errors into one place in order to be printed later, but I haven't investigated whether it is working or not.

To scratch my own itch, i.e. to pinpoint the exact problem in any template files that fail to be parse correctly, especially when trying to convert a Jekyll theme to Hugo, I decided to add this quick-and-dirty one-liner (42b3310):

jww.ERROR.Println(err)

So now a Hugo run on an partially converted Jekyll theme tells me where things go wrong, e.g.:

ERROR: 2015/01/20 template: theme/_default/single.html:7: function "page" not defined
ERROR: 2015/01/20 template: theme/d-i.html:15: function "content" not defined
ERROR: 2015/01/20 template: theme/default.html:15: function "content" not defined
ERROR: 2015/01/20 template: theme/index.html.orig:12: function "post" not defined
ERROR: 2015/01/20 template: theme/partials/Aboutme.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/Archives.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/Blogroll.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/Categories.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/Copyright_Notice.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/Resent_Posts.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/Tags.html:2: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/comments.html:7: function "site" not defined
ERROR: 2015/01/20 template: theme/partials/page_pagination.html:4: function "site" not defined
ERROR: 2015/01/20 template: theme/post/single.html:7: function "page" not defined
ERROR: 2015/01/20 Error while rendering page post/post/hello.md: html/template: "theme/post/single.html" is an incomplete template

which is good enough for solving my problem at hand. :-)

@PhilG, wanna try it out and see if it helps you with porting new themes? :-)

[tatsushid]

@anthonyfok, you are right that Hugo corrects all errors generated at compiling template but these are not used anywhere and I also use the same tips you wrote.

We should improve the behavior but I don't know where is a proper place to add log output code and whether it should stop generating a site or not. Template files are loaded at hugolib/site.go#Site.prepTemplates() but now it doesn't check the errors. The call trace is like

hugolib/site.go#prepTemplates()
hugolib/site.go#Process()
hugolib/site.go#Build()
command/hugo.go#buildSite()
command/hugo.go#build()

[anthonyfok]

@tatsushid, thank you so much for your great input and for showing me the call trace, which I was too lazy to investigate. <grin, duck, run>

You are right: we should improve the behavior and take advantage of the "error message collection" facility. Perhaps @spf13 could shed us a light regarding this design decision? :-)

[bep]

@anthonyfok maybe these errors should be printed when the verbose flag is added?

[anthonyfok]

@bep, these template parsing errors are actually rather serious errors that most definitely cause rendered pages to be incomplete or even blank. They need immediate attention for the users to fix them.

[bep]

OK.

[anthonyfok]

Here is a more concrete example where I have intentionally introduced errors in the template files:

$ hugo
ERROR: 2015/01/31 template: _default/single.html:9: unexpected {{end}}
ERROR: 2015/01/31 template: index.html:8: function "howdy" not defined
ERROR: 2015/01/31 Error while rendering page post/post/hello.md: html/template: "_default/single.html" is an incomplete template

These template parsing errors inevitably lead to the `"xxxxx/xxxxxx.html" is an incomplete template" error, and Hugo would just stop right there in the middle without even creating public/post/hello/index.html, for example.

[MatthiasWinkelmann]

I ran into this problem and it took me more time to fix than I could ever admit without feeling embarrassed. The cause was a line like:

<script src="/js/stuff.js" />

Which, as everyone knows, obviously, should be:

<script [...]></script>

Nevertheless, the error message was unhelpful:

Change detected, rebuilding site
2017-02-17 05:34 +0100
Template changed hugo/themes/paperback/layouts/partials/head.html
ERROR: 2017/02/17 05:34:17 general.go:236: theme/partials/head.html is an incomplete or empty template
INFO: 2017/02/17 05:34:17 htmlredirect.go:114: Alias "/product/page/1" translated to "product/page/1/index.html"
Built site for language de-de:
0 draft content
0 future content
0 expired content
1 regular pages created
2 other pages created
0 non-page files copied
1 paginator pages created
0 stichworte created
0 produkte created
total in 5 ms

Additionally, I had not previously tried the -v switch. Considering hugo server is run in a development environment, it appears that it should default to being helpful, i.e. at least WARN and ERROR should maybe be enabled by default?

(If you prefer new issue(s) please let me know)

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.