Post 0.146.x - aggregation of multiple themes seems weird?

support
1

Similar to this topic … I’m encountering a similarly surprising behavior that I am unsure is expected or not.

if using multiple themes, IE: as articulated here in issue 4460 configuring them via hugo.yaml:

config/_default/hugo.yaml:

#config/_default/hugo.yaml
# ...
header:
  layout: "grace"
# ...
theme:
  - `customacmewrapper`
  - `acmethemebase`

it seems like there’s some odd behavior.

say, for example, in acmethemebase there’s a logic loop that looks for a template/partial and falls back to a default partial template if the file doesn’t exist

themes/acmethemebase/layouts/_default/baseof.html:

{{- /* ... */ -}}}
    {{ $header := print "header/" .Site.Params.header.layout ".html" }}
    {{ if templates.Exists ( printf "partials/%s" $header ) }}
      {{ partial $header . }}
    {{ else }}
      {{ partial "header/basic.html" . }}
    {{ end }}
{{- /* ... */ -}}}

mysite # ls -A \
themes/acmethemebase/layouts/partials/header/ \ 
themes/customacmewrapper/layouts/partials/header/ \
layouts/partials/header/ 

layouts/partials/header/:
nograce.html

themes/acmethemebase/layouts/partials/header/:
basic.html     hamburger.html hybrid.html

themes/customacmewrapper/layouts/partials/header/:
grace.html

it seems as if hugo doesn’t find the wrapper theme’s partial…grace when assessing if the template defined in settings exists … instead falling through and including header/basic.html

in 0.145.x and previous, the lookup merge order was roughly

(current site  layouts/...)   
  `-> (customacmewrapper/layouts/...)   
         `-> (acmethemebase/layouts/...)
                 `-> (embedded layouts || templates || partials etc)

now, it seems like the lookup for templates.Exists is scoped… very differently …

I’m not quite sure what the “as intended” behavior is here, but it’s certainly a deviation from 0.145.x behavior.

Is multiple theme composition no longer a supported pattern?

I can’t share a repo that demonstrates this at the moment

I have spent the last several days trying to adapt the upstream theme, and my own wrapper, to the changes in 0.146.x … just to get to a point where I could build my site again so I could make a post about something completely unrelated… only to hit this…

This came as a pretty big surprise to me..

So…

SHOULD this work still?

If it’s SUPPOSED to work, and it’s a bug, I can try to piece together an exemplar illustrating the problem,
But I don’t want to go thru the effort if the answer is going to be a Don't do that :slight_smile:

I’m admittedly pretty frustrated, and am sincerely trying to not come across as snarky…

I know we all have lots going on; and this IS just software…

Is this another deprecated pattern and I’m jus really doin-it-wrong across myriad dimensions?

that sorta pain’s usually reserved for tuesdays …

2

Yes.

I have tried to wrap my head around what you write and quickly tested a few variations of the above (tested OK), and I’m not able to guess what’s going wrong in the above.

What you’re saying is that template.Exists "partials/header/grace.html" returns false, right?

3

ok… if this SHOULD work, ill get a repro together

It wasnt clear to me if this was still a supported model.

I really DO appreciate all the effort y’all put into hugo, and I don’t mean to be snarky or antagonistic…

I’ve just hit a seemingly unending series of pseudo-unrelated stumbling blocks and cant-quite-get-there-from-here’s trying to get things back to homeostasis, and was pretty damned exasperated by the time I got here :wink:

will post back with an exemplar

4

If you place the file in layouts/_partials (with underscore, recommended):

{{ templates.Exists "_partials/foo.html" }} --> true
{{ templates.Exists "partials/foo.html" }} --> false

If you place the file in layouts/partials (without underscore):

{{ templates.Exists "_partials/foo.html" }} --> true
{{ templates.Exists "partials/foo.html" }} --> true
5

hai joe,

that’s interesting!

may I ask for some help shoring up the underling philosophy to maintain when deciding if one should place content in layouts/_partials as opposed to layouts/partials going forward?

should all partials live in layouts/_partials? or just ones that are overloading an existing artifact somewhere deeper down the merge hierarchy ?

should shortcodes follow similar logic?

layouts/partials/shortcodes?

layouts/partials/_shortcodes?

layouts/_partials/shortcodes?

layouts/_partials/_shortcodes?