I’ve seen in a few child themes that they keep author information in the page front matter. That seems like it could be hard to maintain. What I’d like to do is keep a list of authors in my site params, like so.
Then it should be as simple as setting Author = “Derek” in my page front matter and it will pull from the site config file, making any author changes very trivial.
{{ .Site.Params.authors }} returns the map of authors like I want. {{ .Site.Params.authors.Derek }} returns the single author, which I can then use easily.
My problem is being able to access the map dynamically, based on {{ .Params.author }}. I have tried a few variations, but nothing seems to work:
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"
...
+++
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.
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.
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.-->
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’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.