that’s right
Precisely.
But a shortcut that gives us access to the full range of Hugo’s powerful section functions.
For example one could render a taxonomy terms menu simply by doing this:
<ul class="brand-menu"> {{ range where .Site.Pages "Section" "brands" }} <li class="brand"> <a href="{{ .Permalink }}" class="brand-link"> {{ .Title }} </a> </li> {{ end }} </ul>
And that is just amazing! So bravo @guayom for showing us the light!
I’ve always tried to avoid using taxonomies unless I really had to use them, because of the challenges the Hugo taxonomy model presents when one needs to inject different medata or other things like a banner per taxonomy term page.
Not anymore.
1 Like
Exactly, and that is actually the answer to the OP. If you need a dynamic list, list pages and not taxonomies.
1 Like
One more thing.
This works with Hugo’s default pretty URLs not with the Ugly URLs setting.
Of course I don’t use these but I’m just pointing it out for anyone who uses Ugly URLs.
@guayom Can you point me to your source organization? I worry the discoveries/undocumented eatures/etc could be confusing a lot of people, including me 
Thanks!
You only need to follow the steps specified here and see with your own eyes:
Place the following where you please in _default/list.html
{{ range .Site.Taxonomies }} {{ range $key, $value := . }} {{ if eq (urlize $key) (urlize $.Title) }} {{ range $value.Pages }} {{ .Title }}{{ .Params.logo }} {{ end }} {{ end }} {{ end }} {{ end }}
Specify a brands taxonomy in your config and assign it to posts.
Then under /content/brands/ instead of creating an _index.md simply create a taxonomy-term.md e.g. nike.md
Give it a different .Title parameter.
Run hugo server
Visit /brands/nike or whatever.
See and believe!
1 Like
Yes, just follow the steps @alexandros mentioned. Also, shortly I’ll upload a very detailed post about this.
Cool. But can I please see the source organization so that I can see how this is affecting a particular use case? When we switched from index.md to _index.md, people often found they were getting “desired” results in an “undocumented feature,” but that was most definitely not the case. I’m not weighing in one way or the other; I just need to confer with the gurus before building out documentation around something, please
Sure… do you mind if my repo is completely in spanish? Now I regret not having done it in english.
The _index.md would be in the content. The index.html would be in the /layouts/ folder.
You would add content in _index.html. At index.html you would add your template. It’s better if you use list.html, as @alexandros pointed out.
@guayom I just opened a Github issue about this undocumented Hugo behavior to ask the Hugo Dev Team whether this is safe to use in our templates or whether they consider it a bug. So I would wait if I were you before posting a Tips And Tricks.
you can also cross post that to the dev gitter.im chat
No. I will not open a gitter account. LOL!
I already half expect @bep to smack me down for opening the Github Issue as is. LOL!
But we absolutely have to know if we can use this.
lol, you have a git hub account, that’s all the gitter access you need already, it’s a github app, after all.
Whatever it is I’m really not into chatting with the Dev Team. LOL!
I love gitter.im. I didn’t know there was a channel! Thanks
Now, if you think about this, all you’re doing is creating pages for each taxonomy term. Instead of using the default taxonomy templates, you’re using your own, and leaving taxonomies just to categorize the content.
Yes but down the line there might be a breaking change. So I opened the Github issue to notify the Dev Team. Feel free to comment on Github also.
There are tangible benefits with this approach, but the maintainers might think it has drawbacks. I simply don’t know that’s why I took this to Github.
Yeah, fair enough!
I hate gitter. It’s a dumpster fire of a communication tool.
1 Like
@guayom See the Github Issue. This behavior is considered a bug.
So until we get some kind of clarification regarding what the Dev Team intends to do, I would be reluctant to use this approach on a production site.
@alexandros Thanks for your help with this! I appreciate it.
I created this github repo to show everybody what I’m doing and how to reproduce it. I’m trying to explain everything in detail and how it works. I also deployed it to netlify.
Hopefully with this repo, the dev team can understand exactly what I’m doing. There is really no magic here. I’m using regular pages to replace the default taxonomy pages that hugo would create for me.
Now that I’ve given it more thought, it’s actually a nice way to keep tasks well distributed.
Pages are responsible for holding content
Taxonomies are responsible for organizing content
Hugo is smart enough to create a page for each taxonomy term. That is a powerful feature and a great time saver when you have taxonomies that only need a title and a permalink, for example ‘tags’. But if you need to attach content to a taxonomy, and using the responsibility distribution described before, the proper place to put it is in a page. So the idea here is to override the default /taxonomy/term page that hugo kindly creates for you with your own page.