Now running on Blogit: A Ruby on Rails blogging Engine

Over the past few weeks I've been working on a Ruby on Rails gem named blogit and today I've relaunched my own blog (this site) using blogit to handle pretty much everything.

The concept of blogit is simple: Add a blog to your Ruby on Rails application with as little effort as possible! The gem comes with everything you need to get started, and quite a few options which you can set to optimise your setup.

To Install Blogit

Add this to your Gemfile

gem "blogit"

...and run bundle install to install the gem.

Next, run:

# add an initializer to config/initializers with all of the configuration options
$ rails g blogit:install
# This will add the necessary migrations to your app's db/migrate directory
rake blogit:install:migrations
# This will run any pending migrations
rake db:migrate

then add the following to your routes.rb file:

# config/routes.rb
mount Blogit::Engine => "/blog"

... and finally, declare which of your models acts as blogger in your app (usually User).

class User < ActiveRecord::Base

  # This method adds all of the required associations etc.



Running rails g blogit:install will add an initializer file named blogit.rb. In here you can set various configuration options. Here's a quick rundown of the options currently available:

  • :include_comments - Should blogit provide comments too? (defaults to true)
  • :current_blogger_method - The name of the controller method we'll call to return the current blogger. (defaults to :current_user)
  • :blogger_display_name_method - what method do we call on blogger (User) to return their display name? (defaults to :username)
  • :datetime_format - Which DateTime::FORMATS format do we use to display blog and comment publish time (defaults to :short)
  • :posts_per_page - Number of posts to show per page using Kaminari (defaults to 5)
  • :highlight_code_syntax - Should code blocks be highlited using Pygments? (defaults to true)
  • :authentication_method - The name of the before filter we'll call in the controller to authenticate the current user. (defaults to :login_required)
  • :author_edits_only - If set to true, only the user who authored the post may, edit or destroy (defaults to false)
  • :ajax_comments - If set to true, the comments form will POST and DELETE to the comments controller using AJAX calls. (defaults to true)
  • :include_admin_actions - If set to true, the create, edit, update and destroy actions will be included. If set to false, you'll have to set these yourself elsewhere in the app (defaults to true)
  • :include_admin_links - If set to true, links for new posts, editing posts and deleting comments will be available. If set to false, you'll have to set these yourself in the templates. (defaults to true)
  • :default_parser - The default format for parsing the blog content. (defaults to :markdown).
  • :redcarpet_options - When using redcarpet as content parser, this is the options hash for Redcarpet
  • :cache_pages - Should the controllers cache the blog pages as HTML? (defaults to false).


The view templates will probably need tweaking to suit your own site. For this reason, I've tried to break the views into as many modular partials as was practical. This means if you want to change only how the header is displayed, you only have to change the _post_head.html.erb. You can nosey around the blogit repository to see how the view templates are broken up.

Still in Beta...

The gem is still in beta while I settle on which configurations and features would suit most people. In the meantime, please feel free to try it out and suggest features you'd like to see.


How to write a controller spec for a Rails 3.1 Engine

This week I've been building a Rails gem which mounts as an engine.

When I started to spec out the controllers I kept hitting ActionController::RoutingErrors telling me that no route matches the controller and action I was testing.

I knew this had to be a problem within my specs or with Rspec itself because routes worked fine in the browser.

On poking around the Rails ActionDispatch::Routing code I discovered the :use_route option.

Applying this to the controller specs was the fix I was looking for!

Here's a quick demo:

# in my_gem/spec/controllers/my_gem/my_controller.rb
require "spec_helper"

# Where MyGem is the namespace I've isolated my Gem under
describe MyGem::MyController do

  describe "GET /index" do

    # get the index action
    def do_get
      # :my_gem should be the name of your engine
      get :index, :use_route => :my_gem
    it "should not raise an error when I try a simple GET request!" do
      lambda { do_get }.should_not raise_exception



If you have any interesting Rails 3.1 engines that you're working on, leave a comment with a link below :)