How to access .Site.Params map with a .Params variable

Try the index function
http://golang.org/pkg/text/template/

3 Likes

That worked perfectly. For anyone else who is interested, here’s the code I used to get my author variable.

// In my partial ("Joe" is the map key in this example)
{{ $author := index .Site.Params.authors .Params.author }}
Name: {{ $author.name }}
Bio: {{ $author.bio }}

// In the page params
+++
author = "Joe"
...
+++

5 Likes

Nice. This still leaves a little duplication for me, here’s what i have:

params:
  staff:
    -
      name: "Robert Baratheon"
      title: "King"
    -
      name: "Cersei Lannister"
      title: "Queen"
    -
      name: "Joffrey Baratheon"
      title: "Prince"
  bios:
    "Robert Baratheon":
      bio: "Killed by a boar"
    "Cersei Lannister": 
      bio: "Alive [redacted spoilers]"
    "Joffrey Baratheon": 
      bio: "Poisoned"

Here’s what I’d like to have

params:
  staff:
    -
      name: "Robert Baratheon"
      title: "King"
      bio: "Killed by a boar"
    -
      name: "Cersei Lannister"
      title: "Queen"
      bio: "Alive [redacted spoilers]"
    -
      name: "Joffrey Baratheon"
      title: "Prince"
      bio: "Poisoned"

I have the former structure because of section of my site that just lists all the staff, e.g.

<ul>
  {{ range .Site.Params.staff }}
    <li>{{ .name }}: {{ .title }}</li>
  {{ end }}
</ul>
1 Like

That’s exactly what my code allows for. You can still range through authors/staff like normal, but if you need to get an individual’s details, you can access it through the map. You’re essentially just assigning a unique username to each use for lookups, so you don’t have to duplicate author info per post.

params:
  staff:
    Robert:  
        name: "Robert Baratheon"
        title: "King"
        bio: "Killed by a boar"
    Cersei:  
        name: "Cersei Lannister"
        title: "Queen"
        bio: "Alive [redacted spoilers]"
    Joffrey:  
        name: "Joffrey Baratheon"
        title: "Prince"
        bio: "Poisoned"

Then your output function should still work exactly as you’ve written it. I’m not a YAML person, so my syntax may be wrong, but instead of just having an array of staff, you now have a key / value mapping of username : staff.

3 Likes

Yeah that makes sense. I kinds wish i didn’t have to duplicate the first name though. Not a huge issue though, just being nitpicky :).

@DerekPerkins Would you mind adding this to the documentation? It’s a great example of using site params.

No problem, I’d love to. Thanks for pointing me in the right direction.

@DerekPerkins Is this in the documentation somewhere now?

I also am wondering if there is are any improvements to do this with Hugo 0.13? (Data Files?)

Thanks, Nathan.

With the introduction of data files under /data in 0.13, I think the discussion above needs some rethinking.

I wouldn’t clutter down my config.toml with lots of data … when I could get a much cleaner setup by doing

/data/site/authors.yaml 

etc.

Is this worth a “how-to”?

3 Likes

I wrote this originally for the Gitter channel before reading what @bep says above (which I agree with).

@DerekPerkins

I think we think alike on these things. That said, does it make sense to add distributed authorship information to a configuration file? It works for 4 authors, but what if you have 50? Would it make more sense (and to be efficient and easy to grok, this might mean an adjustment in the data/content model for Hugo, I think) to have content/authors and then have individual .md files for the authors? Then you could use the archetype instead, which is really a “content type,” in which case author is most definitely a content type.

Or just have it as a single .json/.toml/.yml or whatever in the /data/ (or maybe /data/authors/) directory? Then you would make the “join” in the templating layer (using an include for easier abstraction/management):

<!--my-article.md-->
---
title: My Article
date: 2016-02-11
publishdate: 2016-02-12
description: This is the SEO description of my page. Yada yada yada.
author: Ryan Watters
include_bio: true
---
<!--CONTENT-->
<!--???/authors/ryan-watters.yml or /content/authors/ryan-watters.md-->
---
first_name: Ryan
last_name: Watters
midde_initial: D
credentials: balluh
social:
- twitter
    - mytwitterhandle
- facebook
    - myfacebookurl
bio_short: Lorem ipsum dolor sit amet, consectetur adipisicing elit.
bio_long: ...
<!--You get the picture-->
---
<!--partials/whatever/author-partial.html to be included in /layouts/articles/single.html. This range isn't tested and I'm pretty confident it doesn't work, but this illustrates the logic.-->
{{$article-author := .Params.author }}
{{$includebio := .Params.include_bio }}
{{ range .Site.Section.authors}}
    {{ if and (eq (add ".Param.first_name" " .Param.last_name") $article-author) $includebio }}
    <div class="author-info">
        <h3 class="author-name">{{.Param.first_name}} {{.Param.last_name}}</h3>
        <p class="author-bio">{{.Param.bio_short}}</p>
    </div>
    {{ end }}
{{ end }}
<!--using a "where" statement might work better, but again, just demoing the thought process of treating both authors and articles/posts as separate content types.-->
1 Like

My gut feeling is to use either a single authors file or /data/authors/, though admittedly I’m haven’t used data yet so I’m not sure. The benefit of making an actual content file would be the full use of markdown for the bio.

Another piece to consider here is author archives.

I think the important part here is that someone defines a standard way of doing it, so themes can get in line.

2 Likes

Agreed. Here’s the other related thread about it. https://discuss.gohugo.io/t/hugo-seo-social-partials/353/16

I made a stub in Nov '14, but I’m not sure how relevant it still is or if it is even in use. https://github.com/spf13/hugo/commit/8f6f871f539a24347388dec1927adf955248cb53#diff-5e2f089bbc5b15c57e19bc534d8762fe

And to add on to that, “that standard” may have include more than one place to store the into (config for simple stuff vs /data for more complex)

With that in mind, I’ll just start with authors.toml and the original proposal. @bep Where do I start in terms of loading a new site level file?

That is a good question … I guess just put it in viper.Get(“siteConfig”) with a default in /data/site … ?

I’ve started and I think I’ll just use /data/authors for now, but I’m still going to use func (p *Page) Author() to wrap the functionality so that we can change the backing data source without breaking anything.

Sure, thats good …

Check out this PR that handles most of what we discussed
https://github.com/spf13/hugo/pull/1850

1 Like