arresteddevops/ado-hugo

Create a workflow for slugnames

mattstratton opened this issue · 4 comments

Every episode will end up having three URL's

  • The episode number arresteddevops.com/72
  • A listener-friendly version arresteddevops.com/fireside
  • An SEO-friendly version arresteddevops.com/fireside-chat-with-bryan-cantrill

(the specifics of SEO-friendly can vary; while the example used the guest names, it is not necessary, but highly suggested. When constructing that URL, think about it as "human readable", not necessarily "human rememberable". So this is good:

arresteddevops.com/learn-devops-hiring-with-jill-jubinski
and this is less good
arresteddevops.com/jill-jubinski-devops-hiring

The only version of the URL you need to know prior to recording is the "listener-friendly" version, as it will be mentioned during the recording.

Ideally, we don't want that URL to 404 if someone is listening to the livestream, so it would be ideal to have that URL actually "do" something prior to the recording. We can handle this in a few ways:

  1. Add it to the static/_redirects file, pointing to a "coming soon for this episode" page, which would require us to create a new Page type for "upcoming". This could actually be pretty rad, because it could include the link to the YouTube live, and could even pre-populate using guest information as well as sponsors. Then, when the new page goes live, we delete it from the static/_redirects file.
  2. Create the aforementioned "upcoming" Page type, and just name it the listener-friendly slug. Then, as part of the episode going live, you just delete this one first. The downside of this is that Hugo will complain (probably) about you having two pages with conflicting URL's (since the new episode file will have the old slug as one of its aliases), so it could make a wonky git workflow if you need to keep an episode as "draft" for a while.
  3. Add it to the static/_redirects file just pointing to a common "coming soon" page that doesn't reference the episode at all, or even maybe just redirects to the homepage (I like redirecting to the homepage the absolute least, since it really confuses the person hitting the link).
  4. Create the page in advance, and we add a frontmatter parameter called "published", and all of our feed/homepage queries display only episodes that are "published". The downside of THAT is that the episode page depends so much on data we don't have, such as mp3 URL, etc, that we would have to do a ton of error trapping.

Of the choices above, my preference is either 1 or 2, with a preference on 2 (since you run a lesser risk of messing up other redirects if you don't touch that file).

This is basically solved if we stop livestreaming, which we probably should.

@bridgetkromhout @trevorghess what say you?

I think the solution is to follow #1, but only if there is going to be a livestream

Since we no longer either livestream or say /epnumber aloud, I think this is resolved. Is there anything left to do here?

Agreed. Closing.