Closed yazzpro closed 5 years ago
@jaropawlak, great idea. Thanks for contributing!
Before I merge, we need to refactor your code to avoid the following pitfalls:
Hardcoding a given section (posts). Instead, we ought to add a config string on config.toml
file. This string ought to be optional, so that whenever it's not specified, the template should default to the .Site.RegularPages
or .Paginator.Pages
.
This way, one can choose to use the default or a folder of their own choice e.g posts, blogs, articles ...
Avoid breaking taxonomy pages (tags, categories) because they currently rely on the archive partial.
@VincentTam, would you care to chime in?
Based on the home page of my demo site, I confirm the observations made by @jaropawlak of the default behavior of the post list on the master
branch.
I've been scratching my head to give a real-world scenario of @onweru's concern: say we have a course website.
exercises
, tests
, exams
, posts
answers
, hints
, pages
The above type names, if not defined in our codebase, will be defined in the site's (instead of the theme's) layouts/
. Due to the following two hard-coded lines, the user would have to refactor the site list him/herself.
https://github.com/onweru/hugo-swift-theme/blob/4de1506289af2aa36ead5644e7d94c0c2a98902d/layouts/partials/aside.html#L8 https://github.com/onweru/hugo-swift-theme/blob/4de1506289af2aa36ead5644e7d94c0c2a98902d/layouts/partials/archive.html#L2
Compare this with the approach in Beautiful Hugo, the blog theme that I used for my blog. There's no where
in the whole layout file for post list, but it can list posts without (about) pages in the home page of its demo site: https://themes.gohugo.io/theme/beautifulhugo/. I've applied halogenica/beautifulhugo#225 to my blog, and the post listing logic works well without a single word where
. You may check the source code for my blog at https://gitlab.com/VincentTam/vincenttam.gitlab.io/tree/master. I have not modified layouts/_default
.
To sum up, your PR is a way to get rid of the about page in the home page, but I believe there're more elegant ways to do that.
I've been scratching my head to give a real-world scenario of @onweru's concern: say we have a course website.
By default, the exampleSite has one nested directory inside the content
directory. That directory is posts
. However, I may want to have several directories just to ease navigation between categories (on my editor's file tree). Similarly, sometimes you may want to modify the posts
directory to something else (you know, out of meer personal preference)
That's when hard coding the section becomes problematic.
In the other themes mentioned above, there is a place where where
is commonly used: the site's home page layouts/index.html
, for listing only posts. For other common "site-wide" places like layout/_default/index.html
, layout/_default/taxonomy.html
, there's no such reference.
You might run into a situtation where
this keyword is necessary. Define your own content type then, and do whatever you want within the layout files for your custom content type and/or archetypes.
My concern is that this PR is changing "theme-wise" files (layouts/partials/a*.html
) that will be, by default, applied to all content types.
https://github.com/onweru/hugo-swift-theme/blob/69541d134cd236e8c2e5fdf6c0f91bfbeebed32c/layouts/_default/list.html#L1-L3 https://github.com/onweru/hugo-swift-theme/blob/4de1506289af2aa36ead5644e7d94c0c2a98902d/layouts/partials/aside.html#L8 https://github.com/onweru/hugo-swift-theme/blob/4de1506289af2aa36ead5644e7d94c0c2a98902d/layouts/partials/archive.html#L2
That's interfering the content list of other content types. You might change the layouts/index.html
, I prefer but not doing so for every types.
I didn't merge the PR ... I just borrowed from it, a little 😉 .
That's interfering the content list of other content types. You might change the layouts/index.html, I prefer but not doing so for every types.
In the commit referenced above, I ensured that only top level pages will be exempted from the archive listing. Everything else will including taxonomies.
By default, the exampleSite has one nested directory inside the
content
directory. That directory isposts
. However, I may want to have several directories just to ease navigation between categories (on my editor's file tree).
@onweru Subdirectories under content
have special meaning in Hugo known as "Content Types". We have a "categories" parameter in the post front matter. You have perform a search git grep -l '^- categories: foo -- content/**/*
to list files of a specific category under a specific path.
By default, the exampleSite has one nested directory inside the
content
directory. That directory isposts
. However, I may want to have several directories just to ease navigation between categories (on my editor's file tree).@onweru Subdirectories under
content
have special meaning in Hugo known as "Content Types". We have a "categories" parameter in the post front matter. You have perform a searchgit grep -l '^- categories: foo -- content/**/*
to list files of a specific category under a specific path.
Great tip. Many folks may, however, not know how to use grep
or may prefer the good-old-not-so-old-familiar-GUI 😉 😄
Great tip. Many folks may, however, not know how to use
grep
or may prefer the good-old-not-so-old-familiar-GUI
Exercise: find an error in the above Git command.
As far as I understand, "categories" are more context-oriented than Hugo's content types. The former depends more on the actually contents itself (e.g. baseball :baseball: , football :football: , etc), while the later adapt to different data structures. (e.g. newspaper :newspaper:, televisioin :tv: , etc). Recall that everything under Hugo is a page.
Recall that everything under Hugo is a page.
Absolutely true. That is why I did not use
...
where .Site.RegularPages "Section" "!=" "page"
...
in this commit 6ba83cb288d1675d8e758633a167ee77e4a9ba0d
I wish I had discovered this page on Hugo docs about mainSections
when I first saw this PR.
To list the most relevant pages on the front page or similar, you should use the
site.Params.mainSections
list instead of comparing section names to hard-coded values like"posts"
or"post"
.{{ $pages := where site.RegularPages "Type" "in" site.Params.mainSections }}
If I had seen that ten days ago, I would have added commits like 56d6e38357984fb992d6e15d984df0f336b7466f on top of the head of this PR.
Hi, this change looks for blog posts in "post" folder under content in order not to display "about" page (and other pages if would be added) among other blog entries