A Ruby on Rails blogging app for the fashionable developer.

Preferences are for the masses. Any real coder knows the easiest and best way to customize something is by hacking code. Because you want your blog to be you, not bog standard install #4958 with 20 posts per page instead of 15. For this you need a clean, simple, easy to understand code base that stays out of your way. No liquid drops and templates hindering your path, no ugly PHP stylings burning your eyeballs.

  git clone git://github.com/xaviershay/enki.git enki
  cd enki
  git checkout -b myblog # Create a new work branch
  bundle install         # Install all the required gems

  cp config/database.example.yml config/database.yml
  # Edit config/enki.yml and config/database.yml to taste

  # Next step needs libxml2 and libxslt1 and their headers
  # On Debian-based systems: apt-get install libxml2-dev libxslt1-dev
  # On Mac OS X: no action required

  rake secret # Paste output into place in config/initializers/secret_token.rb
  rake db:migrate
  rake            # Run tests
  rails server    # Start the server
  # Load http://localhost:3000/admin in your browser

Or for bonus points, fork Enki at github and clone that instead.

Enki is a compact, easily extendable base for your blog. It does this by being highly opinionated, for example:

• Public facing views should adhere to standards (HTML5, Atom)
• /yyyy/mm/dd/post-title is a good URL for your posts
• Live comment preview should be provided by default
• Google does search better than you or I
• You don’t need a plugin system when you’ve got decent source control
• If you’re not using something more than just a basic username/password, you’re a chump
• Hacking code is the easiest way to customize something

Enki uses OmniAuth for authentication. By default Enki supports Google OpenID Connect via the omniauth-google-oauth2 strategy and OpenID 2.0 via the omniauth-openid strategy. Should you wish to use a different form of authentication, you can implement any of the available OmniAuth strategies, or write your own strategy.

You will need a Google account, then:

• Go to https://console.developers.google.com
• Select (or create) your project
• Click ‘APIs & auth’
• Make sure ‘Contacts API’ and ‘Google+ API’ are enabled
• Go to the Consent Screen, and provide an ‘Email address’ and ‘Product name’
• Click on ‘Credentials’ under ‘APIs & auth’ and take note of your ‘Client ID’ and ‘Client secret’
• Wait 10 minutes for changes to take effect

Create a new file called google_oauth2.yml in your config directory, add your ‘Client ID’ and ‘Client secret’ to the file thusly:

GOOGLE_CLIENT_ID: ADD_YOUR_CLIENT_ID_HERE
GOOGLE_CLIENT_SECRET: ADD_YOUR_CLIENT_SECRET_HERE

If you are deploying to Heroku, you will need to set the above as ENV variables instead of using google_oauth2.yml. For example:

$ heroku config:set GOOGLE_CLIENT_ID=my_client_id
$ heroku config:set GOOGLE_CLIENT_SECRET=my_client_secret

Open up config/enki.yml and make sure that the google_oauth2_email value matches the email address of your Google OpenID Connect identity.

Open up config/enki.yml and make sure that one or more of your OpenID identity URLs are included in the open_id value(s).

As of January 2016, Enki no longer uses acts_as_taggable_on_steroids as it has been replaced with ActsAsTaggableOn. Commit 5e97796 contains database migrations that update the existing tag-related tables to be compatible with ActsAsTaggableOn. This is a non-destructive migration so any existing tag records in your database should be unaffected. However, just to be safe you may wish to back up your database before running bundle install and rake db:migrate to upgrade your Enki install.

As of April 2015, Enki no longer uses the open_id_authentication gem. Commit ec85aef contains database migrations that remove both tables used by open_id_authentication and add a new table to store OmniAuth response information. Should you wish to keep any data that you may have currently stored in either the open_id_authentication_nonces or open_id_authentication_associations tables, retrieve this information before you run rake db:migrate to upgrade your Enki install.

Enki can run your blog with a URL path prefix. For example, you can run it at example.com/blog instead of blog.example.com. You can do so with the RAILS_RELATIVE_URL_ROOT environment variable, set either before starting the server or in config/application.rb before Enki::Application. Uncommenting this line in config/application.rb will enable this behavior in all environments:

ENV['RAILS_RELATIVE_URL_ROOT'] = '/blog'

Mephisto is feature packed and quite customizable. It can however be daunting trying to find your way around the code, which isn’t so good if you’re trying to hack in your own features. Enki strips out a lot of the features that you probably don’t need (multiple authors and liquid templates, for example), and focuses on keeping a tight code base that is easy to comprehend and extend.

Enki embodies much of the philosophy of SimpleLog, but does so in a style that is much more consistent with Rails best practices, making it easier to understand and hack the code.

Uses Ruby 1.9.3 or newer and Rails 4. Runs on MySQL or Postgres. Works on Heroku.

git log | grep Author | sort | uniq

If you want to help out, try tackling an open issue. Please include specs for any fixes. Enki is by design feature light. Unless you feel very strongly your feature should be in core, add a link to your fork in the wiki instead.

GPL – See LICENSE

Admin design heavily inspired by Habari