Respect Type and Layout for list template selection #3005

bep · 2017-02-03T16:09:34Z

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.

The text was updated successfully, but these errors were encountered:

tj · 2017-03-03T23:49:21Z

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

tj · 2017-03-04T00:11:58Z

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.

layouts
├── 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.

wildhaber · 2017-03-10T00:22:01Z

@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 (#3116 / #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 :-)

bep · 2017-03-10T00:29:38Z

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.

rdwatters · 2017-03-10T17:48:28Z

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

bep · 2017-03-10T18:17:50Z

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.

rdwatters · 2017-03-10T18:49:36Z

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.

bep · 2017-03-10T19:06:54Z

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.

rdwatters · 2017-03-10T19:17:47Z

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 😄

bep · 2017-03-10T19:21:27Z

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.

rdwatters · 2017-03-10T19:41:23Z

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?

Hupka · 2017-11-30T18:59:34Z

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!

bep · 2017-11-30T19:17:48Z

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.

Hupka · 2017-11-30T19:29:30Z

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...

bep · 2017-11-30T20:10:47Z

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.

fmstuff · 2017-12-01T07:31:44Z

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?

bep · 2017-12-01T08:21:18Z

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.

laurentsenta · 2018-01-03T14:37:54Z

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:

www.singulargarden.com
blog.singulargarden.com
app.singulargarden.com
etc.

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 · 2018-01-03T18:01:05Z

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.

Fixes gohugoio#3005

This commit also has some other nice side-effects: * The layout logic is unified for all page types, which should make it less surprising * Page.Render now supports all types * The legacy "indexes" type is removed from the template lookup order. This is an undocumented type from early Hugo days. This means that having a template in, say, `/layouts/indexes/list.html` will no longer work. * The theme override logic is improved. As an example, an `index.html` in theme will now wn over a `_default/list.html` in the project, which most will expect. Fixes gohugoio#3005 Fixes gohugoio#3245

This commit also has some other nice side-effects: * The layout logic is unified for all page types, which should make it less surprising * Page.Render now supports all types * The legacy "indexes" type is removed from the template lookup order. This is an undocumented type from early Hugo days. This means that having a template in, say, `/layouts/indexes/list.html` will no longer work. * The theme override logic is improved. As an example, an `index.html` in theme will now wn over a `_default/list.html` in the project, which most will expect. Fixes #3005 Fixes #3245

github-actions · 2022-03-01T02:01:05Z

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.

bep added the Enhancement label Feb 3, 2017

bep self-assigned this Mar 10, 2017

bep added this to the v0.20 milestone Mar 10, 2017

bep modified the milestones: v0.21, v0.20 Mar 31, 2017

rdwatters mentioned this issue Apr 17, 2017

Unify template lookup order for pages with type or layout specified in front matter... #3356

Closed

bep modified the milestones: v0.22, v0.21 May 9, 2017

bep modified the milestones: v0.22, v0.23 Jun 7, 2017

bep modified the milestones: v0.23, v0.24, v0.25 Jun 16, 2017

bep modified the milestones: v0.31, v0.32 Oct 30, 2017

bep modified the milestones: v0.32, v0.33 Dec 16, 2017

bep mentioned this issue Jan 5, 2018

Feature request: Ability to override template type (list vs. single) in frontmatter #4230

Closed

bep modified the milestones: v0.33, v0.34 Jan 11, 2018

bep added a commit to bep/hugo that referenced this issue Jan 13, 2018

layout: Respect Type and Layout for list template selection

ac9fb3f

Fixes gohugoio#3005

bep mentioned this issue Jan 13, 2018

layout: Respect Type and Layout for list template selection #4273

Merged

bep added a commit to bep/hugo that referenced this issue Jan 14, 2018

layout: Respect Type and Layout for list template selection

91815c9

Fixes gohugoio#3005

bep closed this as completed in #4273 Jan 14, 2018

dependencies bot mentioned this issue Jan 18, 2018

Update https://github.com/gohugoio/hugo in repo_dependencies.yml from v0.31 to v0.33 matrixik/dobek.pro#6

Merged

twohey mentioned this issue Aug 23, 2019

Content types documentation references fixed Hugo bug #3005 as unfixed gohugoio/hugoDocs#897

Closed

github-actions bot added the Outdated label Mar 1, 2022

github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Respect Type and Layout for list template selection #3005

Respect Type and Layout for list template selection #3005

bep commented Feb 3, 2017

tj commented Mar 3, 2017 •

edited

tj commented Mar 4, 2017 •

edited

wildhaber commented Mar 10, 2017

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017 •

edited

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017 •

edited

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017

Hupka commented Nov 30, 2017

bep commented Nov 30, 2017

Hupka commented Nov 30, 2017

bep commented Nov 30, 2017

fmstuff commented Dec 1, 2017

bep commented Dec 1, 2017

laurentsenta commented Jan 3, 2018 •

edited

laurentsenta commented Jan 3, 2018 •

edited

github-actions bot commented Mar 1, 2022

Respect Type and Layout for list template selection #3005

Respect Type and Layout for list template selection #3005

Comments

bep commented Feb 3, 2017

tj commented Mar 3, 2017 • edited

tj commented Mar 4, 2017 • edited

wildhaber commented Mar 10, 2017

Proposal

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017 • edited

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017 • edited

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017

bep commented Mar 10, 2017

rdwatters commented Mar 10, 2017

Hupka commented Nov 30, 2017

bep commented Nov 30, 2017

Hupka commented Nov 30, 2017

bep commented Nov 30, 2017

fmstuff commented Dec 1, 2017

bep commented Dec 1, 2017

laurentsenta commented Jan 3, 2018 • edited

laurentsenta commented Jan 3, 2018 • edited

github-actions bot commented Mar 1, 2022

tj commented Mar 3, 2017 •

edited

tj commented Mar 4, 2017 •

edited

rdwatters commented Mar 10, 2017 •

edited

rdwatters commented Mar 10, 2017 •

edited

laurentsenta commented Jan 3, 2018 •

edited

laurentsenta commented Jan 3, 2018 •

edited