[SOLVED] Getting taxonomy params from _index.md

I created a taxonomy called stories and in the _index.md for each i have something like the following.

---
story_featured_image: "/stories/simple-things/joanna-kosinska-129039.jpg"
story_title: "Simple things"
story_subtitle: "Tips, Tricks, Apps, and websites to make your life easier"
story_description: ""
story_color: "#4bb9ff"
story_color: "#ecb201"
story_header_height: "300px"
story_published: true
---

On each post belonging to a story, I need to access the params for story_subtitle, and story_description.

My approach was to try to intersect .Site.Taxonomies.stories with .Params.stories but it returned a string error. What would be the proper way to do this sort of query?

@brunoamaral Just thinking out loud here, I wonder if GetPage will get you anywhere here. https://gohugo.io/functions/getpage/ Nothing I’ve tried, but that might be a starting place.

That sounds right to me, and maybe I’m using it wrong but all I get is nil

{{ $thisstory := .Site.GetPage "page" "stories/simple-things/" }}{{ $thisstory }}

I’ve tried this and a few other variations of the path, like “stories” “simple-things” and even the full _index.md

Hey @brunoamaral have you looked into this: Help with author pages ?

@regis, I did and am using that tactic to show the related posts inside that story. When I try to use it to bring out params in _index.md of that story, I get this:

can't evaluate field story_title in type hugolib.WeightedPages

The code that outputs that error is this

 {{ $name := index .Params.stories 0 }}
 {{ $name_url := $name | urlize }}
 {{ range $key, $taxonomy := .Site.Taxonomies.stories  }}

{{ if eq $key $name_url }}
<h2>{{ $taxonomy.story_title }}</h2>
{{ end }}
{{ end }}

Maybe what I am trying to do just can’t be done. :man_shrugging:

How have you organized your project? You are trying to fetch these params from an _index.md Does that mean you have replicated this taxonomy as a folder structure? Where are the relevant content files stored? Is there a reason you don’t want to do this with sections?

Hugo taxonomies are a more complicated model than sections. And it’s more difficult to achieve what you want. But perhaps a link to your repo will shed some light to anyone who would like to help.

So,

  • “stories” is a taxonomy term
  • “simple-things” is a taxonomy in “stories”

You can get those with .GetPage:

  • .Site.GetPage “taxonomyTerm” “stories”
  • .Site.GetPage “taxonomy” “stories” “simple-things”

The .Site.Taxonomies is a map of some object whtat you really need to understand to use (you cannot guess).

.Site.GetPage “taxonomy” “stories” “simple-things”

Wow nice, this is a nice little feat. I don’t think it’s anywhere in the documentation, I can only find about your first exemple.

@alexandros I think you are right and the problem is in the way I organised the content.

After trying @bep suggestions, and seeing nothing output in the template I re-read my code and checked the documentation.

I had both sections and taxonomy “stories” defined.

I’ve update the repo I use with example content: https://github.com/brunoamaral/future-imperfect-DI/tree/master/example-content

So yes, this is looking a bit messed up and I am going to read the part of the docs that discusses sections to see if I can clean it up and maintain the related posts functionality.

But note that I think the the .GetPage for taxonomies is a little bit cranky if you spell it wrong … I get lost in the details here, but if the taxonomy is named “Simple Things”, you may also try that.

@brunoamaral I have tested your repo and it seems that with the way you have already organized your content it is possible to render the Params you need from /content/stories/simple-things/_index.md using something much simpler than .GetPage with taxonomies.

In the template that you already have under/layouts/_default/post.html I’ve fetched a Param with something as simple as: {{ with $.Page.Parent.Params.story_subtitle }}

And the above renders in all posts under /content/stories/simple-things/

@brunoamaral also what @bep posted above works.

There is a discrepancy in your taxonomy naming. Your _index.md is available under /content/stories/simple-things But in your posts you have set your taxonomy as stories: ["Simple Things"] Because of this difference nothing renders since the _index.md is under /simple-things/ and this is the equivalent of a simple-things taxonomy not Simple Things.

If you rename your posts front matter as stories: ["simple-things"] the _index.md will then be picked up and you will be able to render its parameters in your single posts.

TIP: If you want to render simple-things as a title to get rid of the dash and convert to title case, use the humanize and title functions in your templates.

The taxonomy case saga is long … But I like to think about my taxonomy values in front matter as keys, and that they need to either be title cased when presented or that you put the proper title in the front matter.

1 Like

@bep @alexandros thank you very much for your help, this was driving me crazy.

Here’s what I found out: if config.toml lists stories as a taxonomy, and it’s also a section, both methods return nil. So what I am doing now, is dropping those as taxonomies and focusing on just using sections.

This means reviewing my code and setting up the list of related posts bases on sections (will search the forum for that later today).

It will take longer, but I am guessing it will also make the site render faster. Or at least the code cleaner. Either way a win. :slight_smile:

No. Both methods don’t fail.

What happens is that {{ with $.Page.Parent.Params.story_subtitle }} returns nil.
It seems that the taxonomy model takes over when the taxonomy is defined in the config and Hugo no longer thinks of stories as a section (even if it is).

The method {{ with .Site.GetPage "taxonomy" "stories" "simple-things"}} will continue to work even if you define the stories taxonomy in config. (just tested this because I wanted to know)

Like @bep said

Anyway if you think that you will gain in performance go ahead with restructuring your site. But I would advice to backup first and then compare for any gains.

But the bottom line is that you can achieve what you wanted in your first post of this topic right now without having to change everything.