Specs CMS

Before you even ask: yes, the world absolutely does need another CMS. Because none of them are perfect. Also, none of the others I found did exactly what I wanted. So now there’s Specs as well. Clearly I’m biased but I think it’s pretty great. And hopefully it’ll be the last CMS I write, at least for a while.

This site is using it now. The transition, as you might suspect, was super easy. In some ways, I built the CMS up to and around my own needs. But I suspect that my needs are fairly common:

• Store content, configuration, etc., in files
• Can store metadata and body content in the same files (in this case, in YAML and Markdown, though other configurations would be easy to add)
• Be easy to customize
• Be easy to extend
• No goofy stuff

So Specs CMS is built around five central concepts:

• Fields, which are containers for values
• Entries, which are containers for Fields
• Groups, which are containers for Entries
• Specs, which specify how those things should be built and behave
• Views, which are various ways of rendering those things

All these things are written in a real programming language (Ruby and ERB), so you’re not forced to do goofy things like express logic in YAML, or repeat yourself unnecessarily, and you’re not constrained to some subset of the implementation language that the templating language supports (see Twig, Handlebars, etc.)—you have the full power of Ruby in the templates.

It generates static files (currently only HTML, though it’d be easy to add XML views for an RSS feed), and it’s currently “headless”, meaning there is no graphical admin UI yet. You interact with the CMS by writing files and then acting on them via the command line. So if you’re a developer who would rather write code than click around a GUI, maybe check it out.