Hugo: Respect Type and Layout for list template selection

Created on 3 Feb 2017  ·  20Comments  ·  Source: gohugoio/hugo

In Hugo 0.18, templates are selected the same way as in 0.17 -- but we now potentially have front matter for home page etc. where Layout and Type can be specified. I'm not sure how that should work, but we should be able to do better.

Enhancement
Source
picture bep
👍5

Most helpful comment

Is it fairly complicated to add?

On the Hugo scale it is fairly straightforward. This should be restricted to the output package, which is good from a change perspective.

But as this feature may seem obvious, I have never needed it, and it is not anywhere close to the "top 5" most wanted features.

picture bep on 30 Nov 2017
👍2

All 20 comments

👍 lots of small weird nuances trying to get Hugo to work well for multiple landing pages, loving it otherwise

tj picture tj on 4 Mar 2017

Weird I think this is related. I have the structure below, attempting to create:

  • / home page
  • /ping/ product page

The product page works until I added layouts/_default/list.html for the home page, now it no longer picks up page.html's content but displays the homepage for /ping/ instead. Not sure what's going on there.

├── 404.html
├── _default
│   ├── baseof.html
│   ├── list.html
│   └── single.html
├── page
│   ├── copy.html
│   └── ping.html
└── partials
    └── back.html

content
├── _index.md
├── ping
│   ├── privacy.md
│   └── terms.md
└── ping.md

EDIT: nevermind, it's the ping content dir that is making it unhappy. Figured out that it's better to just specify "url" instead.

tj picture tj on 4 Mar 2017

@bep
I'm not sure how that should work, but we should be able to do better.

I know that there are multiple work in progress in this case (https://github.com/spf13/hugo/issues/3116 / https://github.com/spf13/hugo/issues/3154 / and a not so up to date documentation) Therefore I try to give my best to make a proper proposal what I would expect as a user how the lookup order should be covering Type and Layout

Proposal

> /layouts/<TYPE>/<LAYOUT>.list.html # new
> /layouts/<TYPE>/list.html # new
> /layouts/<SECTION>/list.html #new

/layouts/section/<SECTION>.html
/layouts/_default/section.html
/layouts/_default/list.html

> /themes/<THEME>/layouts/<TYPE>/<LAYOUT>.list.html # new
> /themes/<THEME>/layouts/<TYPE>/list.html # new
> /themes/<THEME>/layouts/<SECTION>/list.html # new

/themes/<THEME>/layouts/section/<SECTION>.html
/themes/<THEME>/layouts/_default/section.html
/themes/<THEME>/layouts/_default/list.html

Unfortunately I don't fully understand exactly how the base-of-approach works. But I'm sure that fits well into this grid.

With the above proposal I think we have a proper synch with the single layout lookup order. And personally I would really love to see it, when Layout and Type of Section _index.md-Files would work.

Take this as one proposal how it could work. I have no idea how much effort this is and if you see it the same as I do :-)

wildhaber picture wildhaber on 10 Mar 2017

I have not studied it in detail, but it makes sense.

I will fix this issue as part of my "multiple output types" PR -- I am consolidating the layout resolving into one fully tested unit. And believe me, when we start adding output format to the matrix, we have to stop presenting all the options the way we currently do.

bep picture bep on 10 Mar 2017
👍2

With the above proposal I think we have a proper synch with the single layout lookup order.

How so? Currently, the single.html is not appended the way you have <LAYOUT>.list.html above (i.e, it's not layout.single.html). I think this is all good stuff though, since from what I can tell in the forums, the lookup order could be a common point of confusion.

Here is what I assumed was the single template lookup:

1. `/layouts/<TYPE>/<LAYOUT>.html`
2. `/layouts/<SECTION>>/<LAYOUT>.html`
3. `/layouts/<TYPE>/single.html`
4. `/layouts/<SECTION>/single.html`
5. `/layouts/_default/single.html`
6. `/themes/<THEME>/layouts/<TYPE>/<LAYOUT>.html`
7. `/themes/<THEME>/layouts/<SECTION>/<LAYOUT>.html`
8. `/themes/<THEME>/layouts/<TYPE>/single.html`
9. `/themes/<THEME>/layouts/<SECTION>/single.html`
10. `/themes/<THEME>/layouts/_default/single.html`

Now that I look at, this is actually incredibly clean:
(Type > section > type > section > default) × 2

rdwatters picture rdwatters on 10 Mar 2017

I think we will have to look for another way (a matrix, a table of some sort) to present the layout options -- and look at all the single, list, taxonomy etc. in one view.

bep picture bep on 10 Mar 2017

I think we will have to look for another way (a matrix, a table of some sort) to present the layout options

For the docs, this discussion, or both?

If you are talking about the docs, I have started on this here. I can expand on why it's not in one view if this is what you're referring to.

rdwatters picture rdwatters on 10 Mar 2017

I will wait until I get the output PR in shape -- but in general, I think the template docs are way too wordy, and that includes your suggestion.

bep picture bep on 10 Mar 2017

I think the template docs are way too wordy, and that includes your suggestion.

If the project has a defined audience/user, I can tailor the content accordingly and then make iterative improvements after launch as you would anything else. You are not the audience. Neither am I :smile:

rdwatters picture rdwatters on 10 Mar 2017

You are not the audience. Neither am I 😄

No, but I have answered plenty of questions about this here on and on the forum. And that is the only real data we have at the moment.

bep picture bep on 10 Mar 2017

That is the only real data we have at the moment.

Agreed! That's all I'm going off of too. But that's not the same as defining an audience...

Have users said it's too wordy?

rdwatters picture rdwatters on 10 Mar 2017

@jhabdas this is an open issue; do you bring something new to this issue with your update?

bep picture bep on 19 Sep 2017

Hey @bep, I see you modifying the milestone for this feature every two weeks for a couple of months now. ;-) Do you have a gut feeling if this is going to be implemented sometime soon? Me and my team long for this feature for quite some time now. :-)

But anyway, thanks for the work you put into Hugo!

Hupka picture Hupka on 30 Nov 2017

Do you have a gut feeling if this is going to be implemented sometime soon?

Hard to say. It is certainly up there on the list, but my priorities may seem odd at times. Often I go for the cool stuff before the obviously useful. And now it is bundles and image handling, which is going to be super duper cool.

bep picture bep on 30 Nov 2017
👍1

Well put.

It took me some time to accept that this feature is just not there yet, I felt it was too obvious to be missing. Is it fairly complicated to add? Since the feature is there for article pages, what else does it take then to include it for the list pages? I'd offer my help if I wouldn't be a total golang beginner...

Hupka picture Hupka on 30 Nov 2017

Is it fairly complicated to add?

On the Hugo scale it is fairly straightforward. This should be restricted to the output package, which is good from a change perspective.

But as this feature may seem obvious, I have never needed it, and it is not anywhere close to the "top 5" most wanted features.

bep picture bep on 30 Nov 2017
👍2

Hey @bep ,
I can see the milestone for this issue being modified multiple times for a while now...
So, while I am really looking forward to see "type" and "layout" configuration in list page's front matter working, I am wondering I this topic is actually on your todo list currently :) do you have any estimate on when this will be solved?

fmstuff picture fmstuff on 1 Dec 2017

I am wondering I this topic is actually on your todo list currently :) do you have any estimate on when this will be solved?

No.

bep picture bep on 1 Dec 2017

Thanks for maintaining this project!
@jhabdas made the issue more clear for me.

Another use case:

I want to use hugo to build a few website for different subdomains:

I would like to use a single theme, so that I can reuse the code instead of duplicating css & partials between 3 differents themes.

I'd expect the layout and type frontmatter to simply override the default homepage layout,
so that my theme:

mytheme/
  layouts/
    index.html
    _default/
      single.html
      list.html
    landing/
      single.html
    app/
      single.html

works with 3 different websites with 3 different homepages layouts.
I'd simply change the layout = {landing, app, etc} in each _index.md.

The only solution I found do far is to have a branch for each, it makes updating & sharing the theme not practical.

laurentsenta picture laurentsenta on 3 Jan 2018

After getting to know more about the code, what's wrong with having simply:

/themes/<THEME>/layouts/<TYPE>/<LAYOUT>.<VARIATIONS>.<EXTENSION>

With <TYPE> going from more specific to less specific:

  • frontmatter type,
  • section type,
  • "_default".

And <LAYOUT> doing the same,

  • frontmatter layout,
  • either of ["list", "single"] (I'd add "home" for indexes).

ditto for <VARIATIONS>

  • ["fr", "en"]
  • nothing

and <EXTENSION>

  • ["rss", "html"]

FWIW, I'm going to use
https://github.com/lsenta/hugo/commit/60f23b78d5ceeea7280f8b77ec718ac122583247 until there's something clearer available.

laurentsenta picture laurentsenta on 3 Jan 2018
Was this page helpful?
0 / 5 - 0 ratings

Related issues

ianbrandt picture ianbrandt  ·  3Comments
MunifTanjim picture MunifTanjim  ·  3Comments
moorereason picture moorereason  ·  3Comments
marekr picture marekr  ·  3Comments
crash-dive picture crash-dive  ·  3Comments