Alright, let’s talk about getting author information into your templates without losing your mind. You’ve got two main avenues here: data files and front matter. One is for site-wide consistency, the other for one-off overrides. The choice isn’t just about where the data lives; it’s about who owns it. Is this author information global to the site, or specific to this page? Your answer dictates your tool.

The Global Rolodex: Author Data Files

For information that’s consistent across the entire site—like a bio, social handles, or a headshot—you want a single source of truth. This is where data files shine. In Jekyll, you stick a .yml, .json, or .csv file in your _data directory, and it becomes a global variable you can access from anywhere.

Let’s say you have multiple authors. Creating a file at _data/authors.yml is your play.

# _data/authors.yml
dana_scully:
  name: Dana Scully
  bio: Forensic pathologist, skeptic, seeker of truth.
  twitter: dscullyfbi
  avatar: /assets/images/avatars/scully.jpg

fox_mulder:
  name: Fox Mulder
  bio: Believer. Probably has a "I Want to Believe" poster.
  twitter: mulderfbi
  avatar: /assets/images/avatars/mulder.jpg

Now, in any template or layout, you can access this data via site.data.authors. The magic is in the filename—authors.yml becomes site.data.authors. To pull in Mulder’s bio for a site-wide footer, you’d do this:

{% raw %}{% assign author = site.data.authors.fox_mulder %}
<div class="bio">
  <img src="{{ author.avatar }}" alt="{{ author.name }}">
  <p>{{ author.bio }}</p>
  <a href="https://twitter.com/{{ author.twitter }}">Follow on Twitter</a>
</div>{% endraw %}

The beauty here is maintainability. If Dana gets a promotion and her bio changes, you edit one file. One change, everywhere updates. This is how you avoid the digital version of photocopying a form and handwriting in the changes for every single page.

The Page-Specific Override: Front Matter

But what if you need an exception? Of course you do. This is the web; exceptions are the rule. Maybe you’re co-writing a post and need to list a second author, or a guest author has a different bio just for this one article. This is where front matter author information comes in.

You can define author details directly in a post’s front matter. This data is scoped to that page and its templates, accessible via the page object.

# _posts/2024-03-27-alien-abduction-therapy.md
---
layout: post
title: "The Efficacy of Hypnosis in Recalling Alien Abductions"
author: fox_mulder
co_author:
  name: John Doggett
  bio: Former FBI Special Agent, pragmatic investigator.
guest_author: true
---

In your post layout, your logic gets a bit more complex, and rightly so. You have to check for the override first, then fall back to the global data.

{% raw %}{% comment %} - Check if `page.co_author` exists for a guest author
 - If not, check if `page.author` is a key in our data file
 - If all else fails, maybe use a default{% endcomment %}

{% if page.co_author %}
  {% assign author = page.co_author %}
  {% assign is_guest = true %}
{% elsif page.author and site.data.authors[page.author] %}
  {% assign author = site.data.authors[page.author] %}
{% else %}
  {% assign author = site.data.authors.default %}
{% endif %}

<h3>About {{ author.name }}</h3>
<p>{{ author.bio }}{% if is_guest %} (Guest Author){% endif %}</p>{% endraw %}

The Hybrid Approach and Its Pitfalls

Here’s where it gets fun, by which I mean “a common source of bugs.” You can mix these approaches. A common pattern is to use a string key in front matter (like author: fox_mulder) to pull in the full object from the global data file. It’s elegant until it isn’t.

The pitfall? Typos. If you write author: fox_mulder in your front matter but the key in authors.yml is fox_mulder (note the second ‘r’), your {{ author.name }} will be empty. Nothing will render. No error message. It will fail silently, leaving you to wonder why Mulder’s bio is suddenly, mysteriously absent. Always, always build defensively. Use the {% raw %}{% if %}{% endif %}{% endraw %} tags to check if the variable exists before trying to print its properties. Your future self, staring at a blank page at 2 AM, will thank you.

The best practice? Decide on a hierarchy of truth. My rule is: Front matter for page-specific overrides (guest authors, co-authors), data files for global definitions. Keep your global data clean and consistent, and use front matter to poke holes in that consistency only when you have a darn good reason. It keeps your system predictable, which is the closest thing to sanity we get in this line of work.