Mr eel
A Content Management System That Doesn’t Annoy Me
I’ve used a fair amount of content management systems over the years. They’re all pretty awful. I won’t enumerate over all the reasons, since plenty of other grumpy people have done that already. Instead I thought I might highlight two of the main concerns I have when using a CMS.
I’m an Expert, Let Me Get All Experty
In other words, don’t try to dumb everything down so that a theoretical every-man can use the system. That’s a lofty aim, but seriously unlikely to succeed. I’m not talking about the admin and administration interface, I’m referring to the bits that let you actually build the site — the templates, styles etc.
Plenty of systems expect you to do ridiculous things like edit templates inside a web interface. Bah! I have a text editor for that. Just expose the templates to me in the file system and let me hack them as I need.
Themes? Utterly stupid. No serious CMS should have anything like themes. They increase the complexity of the implementation for little benefit. Having to hack a theming engine because it’s doing something stupid or is otherwise inflexible is annoying.
Basically, if we assume that a CMS and accompanying templates/styles will be set-up by people who understand how websites work, we don’t need to try and get clever with the implementation.
Extending the System Should Not Mean Using a Narrow API
If you use a CMS for a lot of client work you will have them ask for custom functionality. This is inevitable, so it’s vital that you are able to extend the CMS without going insane.
This comes in a number of forms:
- Plugins for common components — image galleries, forums etc
- Custom, site-specific code
- Over-riding default behaviour in the CMS itself
Most CMSs attempt to solve this by implementing a plugin API. Initially this seems simple enough, but it has some draw-backs. Generally you are limited to what the API gives you.
As for modifying the code in the CMS proper; OMG ARE YOU CRAZY? If you’re reduced to hacking the CMS into a custom version, you will lose your shit at some point in the future. Firstly, you need to maintain those changes — think you can remember the modifications you made in someone else’s code-base all those months ago? Secondly, upgrading is going to kick your arse, because you’ll need to remerge your hacks, then make sure they work.
Let’s Make Yet Another CMS
So that’s all basically an introduction and justification for making another CMS. As part of my work at Freerange Future we’ve been developing a new system. I know, I know, every web-shop seems to go out and make it’s own CMS, but honestly, this is gonna be worth it.
It’s built on top of Merb, MIT licensed and implemented as a merb-slice, meaning we can easily over-ride it’s behaviour and still upgrade it without going nuts. I also t plays nice with your own code.
Most importantly in my opinion, it doesn’t assume you’re an idiot. It won’t hold your hand, instead it assumes you know enough Ruby to be dangerous, but can be trusted not to take an eye out with it.
It’s called Gluttonberg and it lives in a repository on Github. The README and Wiki go into a little more detail about the implementation and features we plan to build, so if you’re curious, please have a look.
It’s obviously still a work in progress so if you’re interested in contributing please just message me on GitHub (lukesutton) and I’ll give you commit access to the main repo, no questions asked.
With the power of Gluttonberg, it’s my hope that we can power-slam the entire internet.
Comments