Page-Variables

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.

Right, let’s talk about navigating between your single pieces of content. You’ve built a beautiful template for your blog posts or product pages, but leaving your reader at a dead end after they finish reading is a bit like a stand-up comedian finishing a killer joke and then just walking off stage into a broom closet. We need to give them a graceful exit, or better yet, a path to the next interesting thing. This isn’t just good UX; it’s good hospitality.

Alright, let’s talk about .Site.RegularPages.Related. This is Hugo’s built-in attempt at being a mind reader, and frankly, it’s a bit of a party trick. It’s designed to give you a list of pages that are, well, related to the current one. Sounds magical, right? It can be, but like any good magic trick, it’s all in the setup, and if you do it wrong, you’ll just pull a rabbit with two heads out of your hat.

Right, so you want to show off how long your magnum opus on artisanal cheese is, or maybe you just want to guilt-trip your readers into actually finishing that 5000-word blog post. Either way, you’re going to want to calculate reading time and word count. It’s one of those features that seems trivial until you actually think about it, and then you realize there are a few delightful little traps waiting for you.

Right, so you want a table of contents. Seems simple enough. You slap a .TableOfContents on your page and Hugo, being the reasonably intelligent software it is, goes and builds one for you. And it does! Mostly. But like any good friendship, ours with Hugo requires understanding its quirks. It’s not psychic, and it makes a few… let’s call them “interesting assumptions” about your content structure. The most basic incantation is exactly what you’d expect. You drop this shortcode into a template—usually a _default/single.html or a dedicated section template—and magic happens.

Right, let’s talk about getting your words onto the page. You’ve got your content files written in beautiful, pristine Markdown. Hugo has dutifully parsed them. Now what? You need to actually render that content. This is where .Content and .Summary come in, and while they seem simple on the surface, they’re the very heart of your site’s engine. I’ve seen more than a few people trip over the nuances here, so pay attention. The Workhorse: .Content Think of .Content as the main event. When you call .Content on a page object within a template, Hugo says, “Alright, you asked for it,” and serves up the entire rendered content of that page. It’s not the raw Markdown; it’s the final HTML, after all your shortcodes have been processed and your Markdown has been transformed. This is what you’ll slap into your single.html template to show the full blog post or product description. Here’s the typical, no-frills usage: <article class="prose prose-lg"> {{ .Content }} </article> Dead simple, right? But here’s the first “gotcha” everyone encounters: Hugo, in its infinite wisdom, has already wrapped your content in a <p> tag if it’s a paragraph, or the appropriate HTML element. This means if you write a Markdown file that’s just Hello, world!, calling .Content gives you <p>Hello, world!</p>. This is mostly fine until you try to do something clever like wrap it in another element and your HTML structure gets weird. The solution is to understand that .Content is a pre-rendered HTML block, not a string you can easily manipulate with Go template functions. You work around it, not with it. The Art of the Tease: .Summary Now, .Summary is a different beast entirely. Its job is to give you a preview, a snippet to use on listing pages without giving away the whole farm. By default, Hugo calculates the summary as the first 70 words of your content, *but only up to the first occurrence of the `

Alright, let’s talk about the workhorse, the fallback, the template that gets called into action when Hugo can’t find a more specific one: layouts/_default/single.html. This is the “you get what you get and you don’t get upset” of the Hugo templating world. If you create a piece of content—a blog post, a project page, a thought you had at 3 AM about the nature of static sites—and you haven’t created a more specific template for it (like layouts/posts/single.html), Hugo will shrug and hand it to this template. It’s your site’s safety net, and you need to make sure it’s not made of cheap rope.