-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Comments
👍 lots of small weird nuances trying to get Hugo to work well for multiple landing pages, loving it otherwise |
Weird I think this is related. I have the structure below, attempting to create:
The product page works until I added
EDIT: nevermind, it's the |
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 Proposal
Unfortunately I don't fully understand exactly how the 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 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 :-) |
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. |
How so? Currently, the Here is what I assumed was the single template lookup:
Now that I look at, this is actually incredibly clean: |
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. |
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. |
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. |
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 😄 |
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. |
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? |
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! |
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. |
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... |
On the Hugo scale it is fairly straightforward. This should be restricted to the 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. |
Hey @bep , |
No. |
Thanks for maintaining this project! 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
works with 3 different websites with 3 different homepages layouts. The only solution I found do far is to have a branch for each, it makes updating & sharing the theme not practical. |
After getting to know more about the code, what's wrong with having simply:
With
And
ditto for
and
FWIW, I'm going to use |
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 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 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
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. |
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
andType
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: