Showing Updated Date on Jekyll Posts - Without Using Plugins
Let’s say you’ve performed a blog content audit on your Jekyll powered website and identified some popular but older posts that need brushing up. You make the edits, and you want all your visitors to know that the posts are revamped by showing the new date on the post. The naïve way to solve the problem would be to update the date
variable in the post front matter, but has high probably of unintended consequences.1
The simplest way to show an updated date in a post is to use a custom variable in the front matter block of the post and update the post layout to use the new variable. In this post I’ll walk through the steps, and cover some further considerations and alternatives.
Step 1: Creating the Custom Variable
I’ve chosen to create a custom variable named updated_date
and include it in the front matter of the target post. Creating a custom variable is as simple as adding the variable name to the front matter, as demonstrated below:
---
layout: post
title: Really Old Post with Recent Update
date: 1982-10-13 09:00 -0700
updated_date: 2023-03-17 09:15 -0700
---
Step 2: Updating the Post Layout
Adding a variable to a post’s front matter will not necessarily change the way the post is generated. The post’s structure will depend on the structure defined in the _layouts/post.html
. The Jekyll default minima theme has the following post layout for the date:
<time class="dt-published" datetime="{{ page.date | date_to_xmlschema }}" itemprop="datePublished">
{%- assign date_format = site.minima.date_format | default: "%b %-d, %Y" -%}
{{ page.date | date: date_format }}
</time>
On a post, this ends up looking like this:
For my new post layout, I’ve chosen to display both the published date and the updated date. I need to add Liquid flow control to check for the page.updated_date
variable, and output if it exists. I want to add a short description to each date in order to distinguish them. I do this by editing the _layouts/posts.html
to the following:
<time class="dt-published" datetime="{{ page.date | date_to_xmlschema }}" itemprop="datePublished">
{%- assign date_format = site.minima.date_format | default: "%b %-d, %Y" -%}
Published {{ page.date | date: date_format }}
{%- if page.updated_date -%}
 // Updated {{ page.updated_date | date: date_format }}
{%- endif -%}
</time>
For posts with an updated_date
, the new layout will look like this:
That’s it! In the future as I update old posts, I just have to remember to add the updated_date
variable to the front matter, and the next build will include updated date on the post.
Other Considerations
- You may not have a
_layouts/post.html
file in your site, especially if you’ve just started with Jekyll. In that case you’ll have to create one. See the Jekyll documentation for overriding theme defaults. - If you want to show only the most recent date on a post, just use an if-else statement in the post layout file. See Tom Kadwell’s post Adding last modified date to Jekyll for an example.
- Depending on your home layout template, it may be setup to display the
post.date
, which you may want to change.
Automatic Alternatives
I’ve chosen to update post dates manually for several reasons,2 but if that won’t work for you, there are several different ways to achieve similar results automatically.
- Plugins, more specifically last-modified-at. It uses front matter variables just as I’ve outlined in this post, but does the layout work for you. Note: as of the publishing of this post,
last-modified-at
is not on the GitHub Pages plugin whitelist, so you’ll have to jump through some additional hoops to use it with GitHub Pages. - Plugin Hooks. I’ll admit I know little about this option, but you can read more about it this StackOverflow answer and the Jekyll docs on hooks. Like most plugins, hooks are not natively supported by GitHub Pages
- Pre-commit scripts. These will update the contents of a post’s front matter variables before changes are committed. See StackOverflow for more.
- JavaScript. Ryan Baumann shared a neat little trick to use GitHub API to get latest commit for current page. I also really like how Ryan links to the GitHub revision history of a post. I may steal that.
Why “updated_date”?
Without digressing into the hard problems of computer science, I chose the variable name updated_date
over other potential options for the following reasons:
- I used snake_case because other Jekyll variables use it, and I cherish the consistency.
- The
post.date
variable is used implicitly as meaning eitherpublished_date
ordate_published
and I wanted to use a similar term. (again, consistency) - Although used interchangeably, “modified” and “updated” have different connotations. A “modified post” carries the sense that small, technical details of a post have changed, whereas “updated post” suggests that the content of the post has been refreshed or made new. Since I expect the readers of this site to be interested in the latter over the former, “updated” makes the most sense to communicate my intent.3
updated_date
sounds better in my head when I read it compared withdate_updated
.
Further Reading
- Published vs Last Updated Date: Which is Better for SEO?
- Debunking the infamous “Only two hard problems in Computer Science”
Footnotes
-
post.date
variable is used in a lot of places internally to Jekyll. As an example, the default permalink format includes a post’s date in the URL, so when thedate
variable of a post is changed in can break incoming links. ↩ -
Reason 1: If I’m already revising a post, it isn’t a bother to also update a variable. Reason 2: I need the control. All the automated solutions (apart from last-modified-at) use the file modified date to set the “updated” variable. In my opinion a file being modified is not the same thing as a post being updated. Fixing spelling errors or grammar issues are not things I would consider an “update.” Fixing broken links aren’t necessarily an “update.” Adding or removing front matter variables is not a post “update.” I want to reserve the “update” terminology for when there are significant structural or content changes. ↩
-
Not that you, dear reader, will ever see the variable. Unless you are reading this post. In which case I hope you appreciate my attention to detail. ↩