Skip to content
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 · 21 comments · Fixed by #4273
Closed

Respect Type and Layout for list template selection #3005

bep opened this issue Feb 3, 2017 · 21 comments · Fixed by #4273
Assignees
Milestone

Comments

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

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
Copy link

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
Copy link

@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
Copy link
Member Author

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
Copy link
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
Copy link
Member Author

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
Copy link
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
Copy link
Member Author

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
Copy link
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 😄

@bep
Copy link
Member Author

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
Copy link
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?

@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.31, v0.32 Oct 30, 2017
@Hupka
Copy link

Hupka 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
Copy link
Member Author

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.

@Hupka
Copy link

Hupka 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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

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
@laurentsenta
Copy link

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

@laurentsenta
Copy link

laurentsenta 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
https://github.com/lsenta/hugo/commit/60f23b78d5ceeea7280f8b77ec718ac122583247 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
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
bep added a commit to bep/hugo that referenced this issue Jan 14, 2018
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
bep added a commit to bep/hugo that referenced this issue Jan 14, 2018
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
@bep bep closed this as completed in #4273 Jan 14, 2018
bep added a commit that referenced this issue Jan 14, 2018
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
Copy link

github-actions bot commented Mar 1, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants