Can _partials be page-path specific too?

support
1

In New template system in Hugo v0.146.0, we can read:

Any folder in layouts that does not start with _ represents the root of a Page path. In Hugo v0.146.0, this can be nested as deeply as needed, and _shortcodes and _markup folders can be placed at any level in the tree.

Is the last statement also true of _partials? That is, would having layouts/docs/_partials/foo.html make sense / work as an override of the default layouts/_partials/foo.html?

Right now, if I put foo.html under layouts and it’s override under /layouts/docs, then .Render "foo" finds the right file. But if I use partials to achieve the same thing, it doesn’t currently work with Hugo 0.147.4. That is a partial "foo" . inside of docs/single.html uses the default “foo”.

This feels like there are two kinds of layout files (at the top level or in a page-path directory): layouts proper (including base layouts), and include-like files such as “foo”. I feel like these include-like file should go under partials.

Thoughts?

That being said, if partials aren’t meant to work that way, would it be ok to prefix include-like “foo.html” files with an underscore – such as layouts/docs/_foo.html – to make it’s usage clear without adverse effects?

2

See https://github.com/gohugoio/hugo/pull/13614#issuecomment-2805977008.

No. The documentation is correct.

I don’t understand the question. Are you asking if that filename OK, or if it’s supposed to do something different, or are you asking for an enhancement?

3

No. The documentation is correct.

Ok, thanks for confirming.

I don’t understand the question. Are you asking if that filename OK, or if it’s supposed to do something different, …

If the filename is OK and that Hugo won’t process layout file names starting with an underscore any differently than if it didn’t start with an underscore (and so it would be ok to use such a convention).

4

Are the files you wish to prefix with an underscore content views? That is, are they called with the .Render method on Page?

5

Currently, the files are .Rendered via single.html.

After reading “this can be nested as deeply as needed, and _shortcodes and _markup folders can be placed at any level in the tree” from the docs, I thought that it might also apply to _partials, which prompted me to try to use partial instead of .Render for layout fragments, but you’re clarifying that that isn’t the case. I’ll have to stick with .Render.

6

When calling .Render "foo" this layout structure worked as desired:

layouts/
├── posts/
│   └── _foo.html
├── _foo.html
├── baseof.html
├── home.html
├── page.html
├── section.html
├── taxonomy.html
└── term.html

All that really buys you is that content views are clearly distinguishable from baseof, page, section, home, taxonomy, and term.

7

Right.

Thanks again for clarifying about _partials being a top-level-only feature.

8

It also allows for themes to namespace layout fragments (which is an issue I’ve been trying to address within the Docsy project) to avoid accidental conflicts with projects using the theme.