I recently did some volunteer work to upgrade the website for a podcast. I chose to re-write the site from scratch, but needed to migrate all of the existing content. After some research, I determined that Jekyll fit our needs best because:

• One of my own requirements was that the site, and all the posts (episodes) would be under version control.
• I wanted to automate certain parts of the process. Jekyll, being a simple command line application, made this relatively easy.
• I was the sole person contributing to the site, and was comfortable with deploying and updating a website, so a full-blown CMS would be overkill.
• Jekyll, once built, is plain HTML. No databases to manage.

The Old Site

When I took over the web presence of the podcast, it had roughly 4 years of content that needed to be preserved. The old site was driven by WordPress.

• The site itself was a simple WordPress site, based on a template.
• All audio files for the podcast were stored in their own folder, managed outside of WordPress. Fortunately for me, this made several aspects of the migration easier.
• The iTunes RSS feed for the podcast was an XML file that was manually updated. I guess this is an artifact from the “old old” site, before they were on WordPress.
• Each episode had a WordPress post that contained the title, a short description, an image, and a link for the audio.

Podcasting with Jekyll

I wanted the new site to be simple, easy (for me) to update, version controlled, and as automated as possible. First, I had to work out the mechanics of how to actually do podcasting with Jekyll. After publishing several new episodes, I’ve found the setup to be quite nice:

• The site itself is a pretty standard Jekyll blog. Blog “posts” are actually podcast episodes. Generally speaking, they work just like Jekyll blog posts in any other site. To add a new episode, I just create a markdown file in the _posts folder with some YAML frontmatter.
• The iTunes RSS feed (which is what makes this a podcast) is generated just like any other HTML page in Jekyll using the Liquid templating engine. (Based, roughly, on this.)
• The frontmatter for episodes has a few special fields. These are used to populate metadata for the RSS feed, and to link to the correct audio file.
• The Jekyll project is stored in Git. To keep the repository small, audio
• files are stored outside the repository and backed up elsewhere.

The Migration

After developing the Jekyll site, I had to migrate all of the content off of the old WordPress site and into the new Jekyll site. Fortunately, since the audio files were already in a separate folder, they did not require any migration.

Since I was now generating the RSS feed with Jekyll, I needed to import all the necessary metadata into a markdown file for each existing episode. To accomplish this, I wrote a script that will generate Jekyll posts (markdown files) from an existing RSS feed. This was the most difficult (and riskiest) part of the migration because I needed these Jekyll posts to produce an RSS feed nearly identical to the existing one (which was not managed by Jekyll).

After importing all the old episodes, all that was left was to deploy the site. Again, because Jekyll generates static HTML, this was easy. I deployed all pages except index.html while the wordpress site was still live. Finally, deleting wordpress’s index.php and replacing it with the new index.html switched the new site on with no downtime. Because the location of the iTunes RSS feed didn’t move, iTunes and other podcast scrapers did not need to be changed and immediately started picking up any new episodes deployed with Jekyll.

Conclusioin

Exporting the old website from WordPress and importing it to Jekyll was easier than I could have hoped it would be, thanks to a few simple scripts. So far, Jekyll has been easier and more enjoyable to work with than WordPress. It’s also proving to be a great platform for serving a podcast. I’m working on a solution for automated deployment, but that’s a topic for a different post.