New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect Type and Layout for list template selection #3005

Closed
bep opened this Issue Feb 3, 2017 · 20 comments

Comments

Projects
None yet
7 participants
@bep
Member

bep commented Feb 3, 2017

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.

@bep bep added the Enhancement label Feb 3, 2017

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 3, 2017

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

tj commented Mar 3, 2017

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

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 4, 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.

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.

tj commented Mar 4, 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.

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

This comment has been minimized.

Show comment
Hide comment
@wildhaber

wildhaber Mar 10, 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 (#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 :-)

wildhaber commented Mar 10, 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 (#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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 10, 2017

Member

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.

Member

bep commented Mar 10, 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 bep self-assigned this Mar 10, 2017

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

@rdwatters

This comment has been minimized.

Show comment
Hide comment
@rdwatters

rdwatters Mar 10, 2017

Contributor

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

Contributor

rdwatters commented Mar 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 10, 2017

Member

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.

Member

bep commented Mar 10, 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.

@rdwatters

This comment has been minimized.

Show comment
Hide comment
@rdwatters

rdwatters Mar 10, 2017

Contributor

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.

Contributor

rdwatters commented Mar 10, 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.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 10, 2017

Member

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.

Member

bep commented Mar 10, 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.

@rdwatters

This comment has been minimized.

Show comment
Hide comment
@rdwatters

rdwatters Mar 10, 2017

Contributor

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 😄

Contributor

rdwatters commented Mar 10, 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 😄

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 10, 2017

Member

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.

Member

bep commented Mar 10, 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.

@rdwatters

This comment has been minimized.

Show comment
Hide comment
@rdwatters

rdwatters Mar 10, 2017

Contributor

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?

Contributor

rdwatters commented Mar 10, 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?

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

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

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

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

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

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

@EddEdw

This comment has been minimized.

Show comment
Hide comment
@EddEdw

EddEdw Nov 30, 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!

EddEdw commented Nov 30, 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!

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 30, 2017

Member

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.

Member

bep commented Nov 30, 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.

@EddEdw

This comment has been minimized.

Show comment
Hide comment
@EddEdw

EddEdw Nov 30, 2017

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

EddEdw commented Nov 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 30, 2017

Member

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.

Member

bep commented Nov 30, 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.

@fmstuff

This comment has been minimized.

Show comment
Hide comment
@fmstuff

fmstuff Dec 1, 2017

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 commented Dec 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Dec 1, 2017

Member

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.

Member

bep commented Dec 1, 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 bep modified the milestones: v0.32, v0.33 Dec 16, 2017

@lsenta

This comment has been minimized.

Show comment
Hide comment
@lsenta

lsenta Jan 3, 2018

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.

lsenta commented Jan 3, 2018

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.

@lsenta

This comment has been minimized.

Show comment
Hide comment
@lsenta

lsenta Jan 3, 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
lsenta@60f23b7 until there's something clearer available.

lsenta commented Jan 3, 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
lsenta@60f23b7 until there's something clearer available.

@bep 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

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

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

layout: Respect Type and Layout for list template selection
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

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

layout: Respect Type and Layout for list template selection
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

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

layout: Respect Type and Layout for list template selection
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

@bep bep closed this in #4273 Jan 14, 2018

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

layout: Respect Type and Layout for list template selection
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment