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
Setting up authentication
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.
Using Google OpenID Connect for authentication
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
config/enki.yml and make sure that the
google_oauth2_email value matches the email address of your Google OpenID Connect identity.
Using OpenID 2.0 for authentication
config/enki.yml and make sure that one or more of your OpenID identity URLs are included in the
Upgrading to Enki 2016
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.
Upgrading to Enki 2015
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.
URL path prefix
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'
How it differs from Mephisto
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.
How it differs from SimpleLog
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.
Contributors, these guys rock
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