Silent Error with .Render function in v0.163.2+extended+withdeploy

support
1

I’m working on a project I put on the back burner several Hugo versions ago. I’ve recently updated Hugo and resumed work but much of my existing layout is broken and silently failing without an error message.

Below is my IDE with relevant file tree on the left, broken layout file in the middle and Hugo server output on the right.

Screenshot 2026-06-21 at 16.23.29
Screenshot 2026-06-21 at 16.23.291920×1241 246 KB

I’ve pinned most of my issues to .Render calls not working. I can tell the Range is still working properly as I can successfully output episode titles, the next call to .Render is either being ignored or silently failing.

Has there been changes to the way I should be calling .Render or addressing the file to use for the render? Do I need to make changes to my file structure?

Just to help clarify, the layout file is for a type “podcast”, a show. The items in the range are of type “episode”.

Any help is very gratefully appreciated.

2

You now need to put all render layouts at the root of the layouts folder (also note the layouts changed in v0.146.0). See .Render is broken in v147.0 - #2 by bep

3

Thanks for your reply. Unfortunately, like the OP in your linked post, I was relying heavily on Render views so I could organize and keep related bits of code together.

I know the recommended “proper” fix is just dumping them all at the root of the layout folder and using naming conventions to try and organize the resulting mess. This is honestly a terrible solution IMHO.

I’ll be doing the same as the other OP and converting them to partials, where at least I can keep them organized.

Your reply did tell me how to get up and running again and I thank you very much for that.

4

Also an error message instead of it just silently failing would be awesome, just saying.

5

Since only the OP and you have raised this issue in a year, it is safe to assume that your implementations were using an undocumented lookup order that worked before, but was rendered redundant when the lookup order became strict.

Also an error message instead of it just silently failing would be awesome, just saying.

That ship has already sailed. But naming conventions are actually good since you will be misusing partials for a role they are not intended for.

6

Been a while since I read the docs, but best I recall at the time, Render views had to be located in the root of a types layout folder to work. Pretty sure I was using them as intended at the time.

It may be a misuse of partials, but absent any other way to logically organize code it’s the best alternative for me. Dumping everything into the root of layout and cluttering up that directory is a terrible solution.

RE the ship sailing on a warning or error, has it really??? Something just silently failing with no warning or error should always be addressed and I personally don’t think it’s ever too late to fix that.

Cheers.

7

I don’t have enough information (screen captures aren’t very helpful) to provide meaningful guidance, but:

  1. You can place view templates anywhere within the layouts directory, excluding the reserved directories _markup, _partials, and _shortcodes.
  2. If there’s an error, it shouldn’t be silent. Whether the Render method should throw an error when the given template cannot be found is an open question; see issue #15052.

Here’s a test project that demonstrates how Hugo resolves view templates:

git clone --single-branch -b hugo-forum-topic-57290 https://github.com/jmooring/hugo-testing hugo-forum-topic-57290
cd hugo-forum-topic-57290
hugo server
8

Thanks for your reply @jmooring!!! What you said was always my experience in the past. I’m on mobile now and will try to provide a more complete file tree later. I’ll try and do a quick one here though.

Layouts

layouts/episode * this is a type declared in front matter and a folder containing all the relevant templates

layouts/episode/listItems * a folder containing the various render views for the type episode in lists

layouts/episode/listItems/listItem.html * the particular render view in my example that’s not working

I’ll admit my layout is structured deeper than most would consider, but I really like nicely organized code. This always worked fine in older Hugo versions and at the time I originally implemented it, I’m pretty sure the docs stated render views for a type had to be in that type’s layout folder. They don’t seem to work there now.

+1 to the issue that they shouldn’t fail silently. This is always bad. If it were something less obvious, one could conceivably go a long time without noticing.

I’ll look at the sample link you provided later.

Thanks again.

9

In the next release, the build will fail with an ERROR if the Render method is unable to find the given view template. See https://github.com/gohugoio/hugo/pull/15055.

Looking at your description above, I now understand the problem. You have been doing things like this:

{{ .Render "subdir/template" }}

That construct is, at least to me, unexpected. The examples in the documentation, and those that I’ve seen in the wild, are of the form:

{{ .Render "template" }}

Having said that, I do see the value in your approach, keeping the view templates grouped in their own subdirectory:

layouts/
├── posts/
│   ├── _views/
│   │   ├── li.html
│   │   ├── summary.html
│   │   └── title.html
│   ├── page.html  
│   └── section.html   <-- {{ .Render "_views/summary" }}
├── home.html
├── page.html
├── section.html
├── taxonomy.html
└── term.html

The alternative is something like this:

layouts/
├── posts/
│   ├── page.html
│   ├── section.html   <-- {{ .Render "view_summary" }}
│   ├── view_li.html
│   ├── view_summary.html
│   └── view_title.html
├── home.html
├── page.html
├── section.html
├── taxonomy.html
└── term.html

See https://github.com/gohugoio/hugo/issues/15056.

I dug into this a bit. It’s a non-trivial change, and I’m not sure the benefit outweighs the cost.

10

@jmooring Thank you so much for adding the error. Totally awesome of you! That will definitely aid in tracking down the instances I’m sure I’ll miss in places where the failure isn’t as obvious.

Your alternative suggestion is much easier to stomach for me and what I’ll implement. That’s way better than the proposed idea of just dumping them all in the root of the layouts folder.

Thanks again for your time and efforts with this. It is very much appreciated.

11

Actually while trying to implement this I’m still having trouble. I’ve created the simplest of test views.

viewTest.html

<div class="row episode-row">
	<div class="col-md-12">
		<h4>Test View</h4>
		{{ .Description }}
	</div>
</div>

I’m calling it here in home.html

{{ define "main" }}
	{{ partial "blogViews/announcementsView.html" . }}
	
	{{ partial "indexListHeader" . }}

	{{ $paginator := .Paginate (where .Site.Pages.ByDate.Reverse "Type" "episode") }}

	{{ range $paginator.Pages }}
		{{ .Title }}
		{{ .Render "viewTest" }}
	{{ end }}

	{{ partial "pagination.html" . }}
	{{ partial "player-includes" . }}
{{ end }}

I can see the output of all the page titles so I know the range is working properly. Those pages are of type “episode” declared in their front matter. I’ve tried placing viewTest.html in the “layouts/episode” folder and also in just plain “layouts”. It doesn’t seem to output the content of viewTest.html no matter where I put it.

Am I still missing something or do I possibly have bigger problems?

12

Use lowercase.

This is something we should change. When calling shortcodes or partial templates, the arguments and file names are normalized, such that:

Argument File name Match?
fooBAR fooBAR Yes
fooBAR foobar Yes
foobar fooBAR Yes
foobar foobar Yes

See https://github.com/gohugoio/hugo/issues/15057.

13

@jmooring That finally got me in business. Thanks again for your time, patience and help. I also glanced at the numerous issues you created based on this thread. It is all very much truly appreciated.

14

I authored the original post a long time ago, (but I forgot my password to that account! bummer). When I saw the comment from @bep saying, “It’s not easily fixable without breaking the new model,” I had to rethink how to simplify my layouts.

What I ended up doing was:

  1. Convincing the remote data source provider to group their data using a simpler template since the data mostly had similar values but different keys . As a result, I removed all 12 render views and added the simplified code to list.html.
  2. Replacing all JSON files with Pagefind.
  3. Since then, I haven’t had to touch the website, as it now rebuilds daily whenever new remote data is available.

If this feature is going to be reinstated, I would be overjoyed. I also have another website, a mix of podcasts and YouTube clips with various descriptions, running on WordPress, and I might just port it to Hugo.

17

@vichudson1

The following issues have been resolved with v0.164.0:

  • #15052: Throw error when Render method is unable to find specified template
  • #15056: Support subdirectory paths in .Render
  • #15057: Make template name lookup case-insensitive for layout front matter and .Render

See revised documentation: https://gohugo.io/methods/page/render/