Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.
Design wise, it’s a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this:
- Open a text editor and type out HTML and CSS.
Comparing this to other workflows I’ve used in the past, this is definitely the most productive way of working. Some stats:
- Time spent setting up build tools: 00:00
- Time spent wrangling the pipeline to do exactly what you want: 00:00
- Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone for more than a few months: 00:00:00
I have some files. Some images, three font files, a few pages of HTML, one RSS feed, one style sheet, and one minimal service worker script. I don’t need a web server to do anything more than serve up those files. No need for any dynamic server-side processing.
I guess this is JAMstack. Though, given that the J stands for JavaScript, the A stands for APIs, and I’m not using either, technically it’s Mstack.
Netlify suits my hosting needs nicely. It also provides the added benefit that, should I need to update my CSS, I don’t need to add a query string or anything to the link elements in the HTML that point to the style sheet: Netlify does cache invalidation for you!
The mp3 files of the actual podcast episodes are stored on S3. I link to those mp3 files from enclosure elements in the RSS feed, which is what makes it a podcast. I also point to the mp3 files from audio elements on the individual episode pages—just above the transcript of each episode. Here’s the page for the most recent episode.
I also want people to be able to download the mp3 file directly if they want (or if they want to huffduff an episode). So I provide a link to the mp3 file with a good ol’-fashioned a element with an href attribute.
I throw in one more attribute on that link. The download attribute tells the browser that the URL in the href attribute should be downloaded instead of visited. If you give a value for the download attribute, it will over-ride the file name:
<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>
Or you can use it as a Boolean attribute without any value if you’re happy with the file name:
<a href="/files/nice-file-name.xyz" download>download</a>
There’s one catch though. The download attribute only works for files on the same origin. That’s an issue for me. My site is podcast.clearleft.com but my audio files are hosted on clearleft-audio.s3.amazonaws.com—the download attribute will be ignored and the mp3 files will play in the browser instead of downloading.
Trys pointed me to the solution. It turns out that Netlify can do some server-side processing. It can do redirects.
I added a file called _redirects to the root of my project. It contains one line:
/download/* https://clearleft-audio.s3.amazonaws.com/podcast/:splat 200
That says that any URLs beginning with /download/ should redirect to clearleft-audio.s3.amazonaws.com/podcast/. Everything after the closing slash is captured with that wild card asterisk. That’s then passed along to the redirect URL as :splat. That’s a new one on me. I hadn’t come across that terminology, but as someone who can never remember the syntax of regular expressions, it works for me.
Oh, and the 200at the end is the status code: okay.
Now I can use this /download/ path in my link:
<a href="/download/season01episode06.mp3" download>Download mp3</a>
Because this URL on the same origin, the download attribute works just fine.
# Shared by Trys Mudford on Monday, August 17th, 2020 at 11:31am