Why I built my own CMS
Why I built my own content management system, and why you probably don't need to.
Whenever I go for an interview, one of the questions I get asked asked most often is why I made my content management system. My first instinct is to respond, “Why not?”
Since the start of my freelance career, I’ve built blogs using WordPress. In that time, I've built sites for all kinds of people over the years. Politicians, musicians, hobbyists, insurance companies. Sure, I may have used Drupal or Joomla or maybe some obscure set up occasionally when requested, but I would generally fall back to WordPress.
With a few plugins and themes, you can turn WordPress into just about anything. A forum, a social network, anything. Between the custom post types, custom taxonomies, custom menus, inline editors, WordPress has gotten way too cluttered when you just want a platform to write.
As the years would pass, I began to run into more and more problems from all directions. The thing is, WordPress isn't just this blogging platform anymore. It no longer has a specific purpose. And that’s fine, if that's what you want. I would still probably choose it over most other solutions, even today (I still use WordPress on my photoblog, tyler.camera). But as a just a blogging platform, it’s not what a lot of clients wanted. Not to mention all that extra clutter also just seemed to confuse them.
About this time, I had just discovered the python web framework, Django, and was eager to learn how it worked. And what better way to learn than to make my own app for it? So, I started work on a blog engine. The initial app was simple, consisting of only a few pages. A user could login, write, and edit posts, and view upcoming posts. That was it. Similarly to Jekyll, it used Markdown to render the content of posts to html. In fact, nothing about the CMS did anything new.
That’s actually how Replica got it’s name. I literally copied, or replicated, features from other content management systems that I liked or thought were useful, and left out everything else. Initially, Replica was more of a framework for a framework. Every site I used it in, the code was slightly different, altering it however I thought it would best serve the client.
Just about everyone I offered it to was happy. The downside to running a Django website for a client is that it’s not exactly easy to set up for them. You cant just ftp into any web host, upload the files, and be good to go like you can with most php based platforms like WordPress. Hosting atypical sites can also get expensive fast, especially if they don’t have their own sysadmin to keep everything running smoothly. In the end, I retreated back to more traditional forms of hosting and platforms for clients.
If I had the resources, that is, the time and money, I'd consider turning Replica into a real product. One of the most important things when developing a product though, is being able to admit when something isn't viable. Replica just wasn't practical.
That’s not to say I completely stopped writing it. I believe it still has a use. Granted, that use probably isn't for everyone. It’s probably not even for post people. Should you use it for your project? Probably not. But the code is freely available for you to get inspiration from, if you choose to go down the same route I did.
I'm building it for myself at this point. To me it will always remain unfinished. And I'm happy with that. I love using it to explore different venues. It gives me a new perspective in publishing content. I can learn what works, and what doesn’t. I can't even begin to count the times I've torn it down and rebuilt it. I even thought about turning it into a service similar to Medium or Svbtle. But more about that another time.
So what’s the future hold for it? I'm not really sure. I just know I'll continue to tinker with it for the foreseeable future. You can see it in action at my blog, A Life Well Played— Which itself is somewhat an experiment in blogging.