Author’s Note: I’m currently in the process of migrating old blog posts to this new system. That may mean some links, syntax highlighting, and other details are broken or missing temporarily. Sorry for the inconvenience!

In the beginning of the last post, I made a little note that I’ve been having to start writing these blog posts in a rather frustrating way. That is, I find a prior post, copy most of the contents, and then delete the parts that need to be changed. We’ve added a lot of features since our original .txt post. We’ve even gotten to the rather pleasant point where I can write these posts in Markdown, and we’re automatically converting and uploading them to HTML.

However, I’ve had to paste the following at the top of the file I’m working on, just to make sure this post takes advantage of all the things we’ve been working on:

<!DOCTYPE html>
<html lang="en">
<head>
<title>The Need for Post-Processing</title>
<meta charset="utf-8">
<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@cheerskevin" />
<meta property="og:type" content="article" />
<meta name="twitter:title" content="The Need for Post-Processing" />
<meta property="og:title" content="The Need for Post-Processing" />
<meta name="twitter:description" content="An adventure in hiding complexity and being scared of feature creep" />
<meta name="description" content="An adventure in hiding complexity and being scared of feature creep" />
<meta property="og:description" content="An adventure in hiding complexity and being scared of feature creep" />
<meta property="og:url" content="https://cheerskevin.com/real-post-processing.html" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
html {
  background: #666;
  overflow-x: hidden;
}
body {
  background: #fff;
  margin: 10px auto;
  max-width: 960px;
  overflow-x: hidden;
  padding: 5px 10px;
  width: 90%;
}
</style>
</head>
<body>

…and all of that’s before I can even write anything! Today, we’re going to take a crack at a little bit of cleaning up.

We have a build step

In Moving Toward Markdown, we added a build step. This means that the file you’re reading is not the file I’m writing anymore. I write in a .md file, and you read a .html file. There’s a script running on my machine which runs the following command whenever I save my .md file:

markdown $FILENAME > "${FILENAME%.*}.html"

All that does is take the Markdown code that I write in real-post-processing.md, and converts it into HTML code to put into read-post-processing.html. But since we have code doing that anyway…can’t we have it automatically prepend the stuff at the top (and maybe add the closing </body></html> at the bottom)?

Absolutely! We can do that with the following code:

echo "BEGIN" > "${FILENAME%.*}.html"
markdown $FILENAME >> "${FILENAME%.*}.html"
echo "END" >> "${FILENAME%.*}.html"

That’ll write “BEGIN” to the HTML file, then it will append the Markdown-processed post contents, then finally it’ll append “END” at the very end. And, in fact, I could put the “BEGIN” / “END” done stuff in files, and do something like this:

cat templates/prefix.html > "${FILENAME%.*}.html"
markdown $FILENAME >> "${FILENAME%.*}.html"
echo templates/suffix.html >> "${FILENAME%.*}.html"

And then we could put whatever we want in those extra files!

But wait! Stop!

What about our old posts though?! If this builder runs on any of those, it’ll screw them up. What if we need to go back and fix a typo or something? Those old posts are not designed to be messed with!

Here we have a problem. A very common problem, but a problem nonetheless. As we continue to build up this site to do cooler and fancier and better things, our content is going to evolve. But we ideally want to have a way to segment our posts based on what they can support. A decade from now, how will we know which posts are VR-compatible, and which aren’t?!

Okay, so before we do any damage, let’s just make up an arbitrary way to mark posts that support this prefixing/suffixing stuff we’re gonna do. Let’s agree to start the post with the following content:

---
version: 0.1.0
---

...and then the post stuff...

Why three dashes? Why a version number like that? Reasons we’re not going to get into today. But since none of our previous Markdown posts have this content, we should be able to update our script to only do its appending stuff for new files.

And actually, none of our old Markdown files start with ---, so that’s all we really need to check for right now. We just need to make sure we’re backward compatible. So let’s update our script:

if head -n 1 $FILENAME | grep -q '\-\-\-'; then
  cat templates/prefix.html > "${FILENAME%.*}.html"
  markdown $FILENAME >> "${FILENAME%.*}.html"
  cat templates/suffix.html >> "${FILENAME%.*}.html"
else
  markdown $FILENAME > "${FILENAME%.*}.html"
fi

Except there’s one small problem. We don’t want the “—” junk ending up in the post itself. Let’s update the Markdown command to filter that out:

cat $FILENAME | sed '1,/---/d' | markdown >> "${FILENAME%.*}.html"

There’s probably cleaner ways to go about this, but that should work.

Now to populate those templates

Looking at what I’ve been copying and pasting, here’s what we can put in the prefix:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@cheerskevin" />
<meta property="og:type" content="article" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
html {
  background: #666;
  overflow-x: hidden;
}
body {
  background: #fff;
  margin: 10px auto;
  max-width: 960px;
  overflow-x: hidden;
  padding: 5px 10px;
  width: 90%;
}
</style>

That’s the content that isn’t going to change from post to post. Unfortunately, that still leaves the top of the posts looking like this:

---
version: 0.1.0
---
<title>The Need for Post-Processing</title>
<meta name="twitter:title" content="The Need for Post-Processing" />
<meta property="og:title" content="The Need for Post-Processing" />
<meta name="twitter:description" content="An adventure in hiding complexity and being scared of feature creep" />
<meta name="description" content="An adventure in hiding complexity and being scared of feature creep" />
<meta property="og:description" content="An adventure in hiding complexity and being scared of feature creep" />
<meta property="og:url" content="https://cheerskevin.com/real-post-processing.html" />
</head>
<body>

We can’t really extract any of that content, because it’s specific to the individual post. We can’t have the system automatically use the same twitter:title on every blog entry. And we don’t have any system (yet) for extracting that metadata, so that we could inject it into a more robust template.

Our suffix.html file contains the very simple </body></html>, which is at least something. But looking at the content that remains, it’s clear there’s a lot of redundancy still. What I’d like to talk about next time is the content that we’ve got between those “—” lines. By adding a little bit more code, it’s just possible that we can get rid of these remaining obnoxious tags. See you then!


←Previous Post | Next Post→