Ruby Red Bricks

This is from my old site and judging by the traffic the main reason why I get any visitors. While it possibly needs a tidy up - and it exposes some of my naivety from back then - I'm putting it up so people don't get completely cheesed off when they go hunting for the old post.

Rails is a CMS

There are now quite a few content management systems written in Rails. The chief ones would seem to be Radiant and Mephisto-as-CMS but there are dozens – of varying styles and sizes. For a quick overview there is a decent starting point. Please note: this used to be up on wiki.rubyonrails.org, but the site seems to have been trashed. The link points to a local copy retrieved from Google Cache.

The idea of using a framework on top of Rails to build CMSs has never sat right with me. I think of Rails as a kind of meta-language for describing web sites – essentially a mechanism for describing how web content is to be produced and consumed. The restrictions imposed by its architecture are easy to work with and make good sense – I’m not convinced I need to take on additional constraints and other conventions just to leverage code in an existing CMS solution.

But I could be wrong..

An idea I’m curious about: what’s the least you can do to build a working content management system using Rails? Let’s kick off by establishing what’s meant by a “content management system”. Looking back at the “starting point” wiki page there is a list of what the author considers essential features of a CMS:

• Create and edit via redcloth/etc from web
• Access control lists
• Full customization of layout and style
• Pretty urls (no /node/2235133/)
• Subpage Content items, may be referenced freely by multiple owners (graph not tree)
• Staging
• Versioning
• Lives as a component in rails, can reference content in a way similar to render_component in views
• Should produce W3C standard (x)HTML/CSS/Accessibility web site

There has to be more – and indeed there is more on the wiki page – but let’s go with that as a start and refine the spec as we go. What would we need to do to get Rails to cover these requirements without too much head messing?

Rails + Plugins = CMS

There are several plugins that seem to come almost standard these days, the acts_as_X functionality you use to deliver authorization, authentication, logging. The thing I love about Rails is that it doesn’t dictate what tools you should use – you just start with the basic framework and you add whatever you need with either your own code or what you find in gem- and plugin-land. What you use for authorization may not be what I use – though we can be pretty sure there’ll be a class called User in there somewhere that we can shape to our own evil (or good – whatever rocks your boat) ends.

The plugins model works – evident by the way that all the good CMSs end up replicating it via their own extension/plugin frameworks. But there’s a cost you have to pay taking on board someone else’s stack – someone choses a particular set of gems or plugins for example, so you’re stuck with potential incompatibilities with other code. Features are well rounded in some areas and not in others, so you miss out on stuff you want so you can have stuff you need (or need right now). A whole series of little steps and forks in the path that may lead you to commercial/personal/spiritual reward – or completely deplete you. I’m a shocker for picking the wrong horse (ask my long suffering co-workers), so I want to take on as little as possible lest anything turn out to be a dud.

It’s a question of how far you are wanting to go down the path with any vendor and it’s often a difficult exercise. Engaging with like-minded souls is extremely important, so don’t think I’m arguing against cooperation with other developers. Being involved in the open source community would have to be one of the best things to do to keep yourself honest and honed. But I am arguing for simplicity, for valuing code and for knowing what’s going on inside the systems you build. It’s a bit of journey.. so let’s push on.

Create and edit via redcloth/etc from web

RedCloth installs as a gem, as do most of ‘etc’ I imagine. Liquid Templates is another nice way to mark up your views. There’s no shortage of specialized template rendering gems/plugins in use in Rails apps – including existing CMSs.

Access control lists

What level of access do you want to manage? What other authentication technologies (LDPA, OpenID, so forth) do you need to work with? Again, there are a stack of plugins that can cover your needs here. Next..

Full customization of layout and style

Rails’ layouts and views do this out of the box.

Pretty urls

Make graves. Again, Rails does this via routes, restful resources and custom actions.

Subpage Content items

Partials?

Staging

Out of scope – set up a proper staging environment and use capistrano to manage it. And Rails does allow for multiple environments. It’s really dependent on how you run your shop, but Rails does explicitly help here so I’m giving it a tick.

Versioning

Use a version control system.

Lives as a component in rails

Crazy recursive argument brewing. Best leave that one alone.

Should produce W3C standard (x)HTML/CSS/Accessibility web site

No, you should produce standard HTML/CSS and be prepared to hand-craft the damn thing until it works on all browsers more or less the same way. It gets back to knowing what’s going on in your system. How often have you had a website not render in your preferred browser because some clown didn’t know there’s a world outside of InternetExplorer?

There are plenty of things that will make running a CMS on Rails easier. But the fundamentals don’t change between much web apps and Rails does the fundamentals well.

Managing Static Content

One thing any CMS has to do well is manage static content – by which I mean the bread and butter brochureware that makes up the bulk of the typical commercial website. Revisiting and extending our requirements:

• Content must be searchable
• Content must be versioned
• Content must be able to be staged
• Content must be easy to update

Managing static content is a central feature in a CMS. All the fancy dynamic stuff is going to live in your custom controllers and views, as it will live in the custom code of any site aiming to present a unique and/or useful user interface. Dividing the design of the CMS between features addressing frequently changing content and the relatively fixed aspects will allow me to put the dynamic parts of a CMS aside initially and concentrate on looking after the management of static content first.

The Plan

I’ve just realised I’ve said most of this before in an earlier post. Wups! Not only am I getting grumpier I’m getting forgetful. The last post sort of wandered about a bit without actually getting anywhere. I’m proposing this time around I take the outrageous step of building something that works. I’ll be borrowing some ideas from a similar system we use at work, but will be extending it along my own lines. Nothing will be particularly original – I’m not much of a coder – but I’m hoping it will be useful. And I’m kind of keen to pick up some knowledge along the way.

Next Post: The Static Content Controller

• Tags: old-stuff rails-as-cms 
• Meta: 4 comments, permalink