I mentioned in a previous post that I was interested in moving from Octopress to Jekyll because it seemed more supported. I ended up doing it and it took less time than I thought it would. Here’s a quick recap summary.

Basics

I created a new Jekyll 2.0 project and then:

• copied over the existing posts
• copied over the debug blog posts
• copied RSS
• copied existing styles and javascripts
• generally made sure everything worked as before
• got comments working with Disqus

New publishing strategy

To get publish my blog, I previously used a hand-rolled script to copy files to S3. I thought “there has to be a better way”, and some basic research revealed s3_website. This gem rocks. I would recommend it for any Jekyll site deployed to S3. It reduces code that I have to maintain. But wait, there’s more. It checks what is currently on S3 and uploads only the diff. When it figures out what to upload, it can upload gzipped versions in parallel to speed it up. Deploys can go from a minute to about ten seconds. Plus, it has great support for redirects, which I used to give some existing posts and other resources some better names.

I made a staging environment to test out the deploy process and that helped. s3_website also has a --dry-run switch that may come in handy for testing out deploys.

Clean up scripts

While I was at it, I cut down the large generated Octopress Rakefile and replaced them with standalone Bash or Ruby scripts. I think it is better because the scripts are a bit more modular than having one big Rakefile with a bunch of dependencies.

Jekyll relative / absolute URL plugin

With the different environments (local, staging, and production), I wanted a way to specify “the version of this file in this environment”. I also want to use the absolute URL of resources in production so that they are accessible in feed readers. (Subscribing to your own blog is a great way to see issues that subscribers might run into.) I think that I cribbed this partially from Jekyll’s documentation and added some extras. Here’s the plugin:

# Use absolute URLs so images and such show up in feed readers, etc.
# but allow us to preview locally before pushing up images.
#
# usage:  /whatever/you/want 
# output: http://yoursite-or-preview-url.com/whatever/you/want

module Jekyll
  class AbsoluteUrlTag < Liquid::Tag

    def initialize(tag_name, text, tokens)
      super
      @text = text
      @text = "/#{@text}" unless @text[0] == '/'
    end

    def render(context)
      config = Jekyll.configuration({})
      base_url =
        if ARGV.include?('--drafts')
          config['local_url']
        elsif ENV['staging_deploy']
          config['staging_url']
        else
          config['url']
        end
      "#{base_url}#{@text}"
    end
  end
end

Liquid::Template.register_tag('absolute_url', Jekyll::AbsoluteUrlTag)

In your _config.yml you would specify the different configuration variables to make this work.

Smarter quotes

I’m not sure what the best Markdown engine is, or what the default or desired one is on Jekyll, but this seems to work well for me:

markdown: redcarpet
redcarpet:
  extensions: ['smart']

The last part gets me “smart” (curly) quotes. It was a bit difficult to figure out from the documentation how I was supposed to figure that out.

Advantages

Jekyll 2.0 provides better and more native draft support. This is a win for me since this is the workflow that I would like and it is less code that I need to maintain.