With all the debate going back and forth on which is the best CMS, I’d like to take some time to put the case for writing your own.
I realised almost a year ago that my site was getting old in the tooth. It needs to be updated, and not just the design, but the whole functional basis of how content is created, managed and published. It’s getting too big and complex, so I need a CMS — and almost as soon as I realised that, I decided to write my own.
Why I Chose To Write My Own
The first and clearest reason why I chose to write my own, is that I had a very specific idea of what it should do, and how it should work. For example, I wanted to minimize dynamic page creation, so that pages with dynamic content, like category-navigation and tag-lists, are built in advance by admin functions and not as part of the page-view. That’s obviously not always possible, as some things can only be done on-the-fly, but I had a very particular idea of where the split between static and dynamic should be, and I wasn’t confident that any existing CMS would give me precise enough control.
I also wanted a site where every page could be syndicated, either as JSON meta-data or content-only HTML, and so that all the user has to do to get that API content is add
".html" to the page URLs. As far as I know, no existing system can do this without extensive modification.
I’ve worked with WordPress a lot, and I’ve also had a good poke around inside the install that SitePoint uses — and it takes a lot of plugins and custom code to make it all work. I’d rather spend that time writing something new, not least of all because I like building stuff myself.
I also hate browser-based edit boxes, and even the most advanced of them can’t compare with the power and flexibility of a proper text-editor like BBEdit or TextPad. When it comes to every-day maintenance and updates, I have a way of working and tools that help me to be productive, and almost all the browser-based tools I’ve used get in the way of that. My experience with WordPress certainly hasn’t helped, as it constantly frustrates and annoys me by parsing my markup destructively, changing elements, adding breaks, making nice HTML go bad. I don’t want to have to deal with that. I want a system that works with normal text-files which aren’t parsed at all, that don’t have to be sanitized as they’re not stored in a database.
The overhead of using a database at all seems like overkill for a site like mine, when the vast majority of most of the pages is static HTML. I suspect the same is true for a great many blogs — it’s wasteful to make a database query just for a chunk of markup. It may be convenient for developers and managers, but it’s not what’s best for users.
And user-centric thinking brings me to my last, probably most important point, which is that I wanted a strong focus on accessibility in all the client-side code it produces. Content Management Systems are, inevitably, server-side applications, and when a group of developers have such a strong server focus, the client-side often wants for the same attention to detail. I’ve seen it so many times with almost every CMS and forum package I’ve used — when it comes down to a conflict between what’s convenient to build on the server, and what’s the best client-side code to produce — the server always wins.
I wanted to shift that focus so that clean, robust and accessible client-side code would always take priority over what’s easy for the server to generate. And that meant not just a change in priorities for how the server-side is written, but a shift in emphasis away from dynamic pages, to building them in advance.
This is how the SitePoint Reference works — complex, detailed pages are generated from XML, but all of that runs in advance to produce essentially static pages, and that’s what the user retrieves. I don’t know of any CMS that works this way, and the SitePoint Reference itself was a custom solution (primarily developed by Kevin Yank).
The Benefits of Writing Your Own
This is one of those cases where small things have a big impact. Frankly, there aren’t that many benefits to writing your own CMS, but those that there are, are very significant.
The reasons I chose to write my own can all be summarized in a single benefit, that writing a custom solution means you can have exactly the system you want, that does everything you want it to and nothing that you don’t.
And when it comes to actually using the system on a day-to-day basis, writing your own means there’s no additional learning curve. I already know every in-and-out of how my admin interface works, because I wrote it to be intuitive to me. The same is true for updating and improving the system itself, and if I need to add new features later or change the way something works, I’ll already know exactly where to add or change the code.
Using a custom solution also means that you’ll never be a victim of mass security exploits. I used to run a forum powered by phpBB, but it fell victim to a security exploit and was hacked to its knees overnight. I’d spent weeks modifying the back-end and templates to spit-out accessible code, and all of that work was ultimately wasted.
When you use an open-source system, it’s only right and polite to credit the developers, usually with a copyright notice and link at the bottom of the page. Credits like this are great Google juice, but they’re also treasure maps, for any hacker looking for sites with just the right version of just the right package to fall to the exploit they know.
One person can destroy a hundred vulnerable sites in an evening. But you’ll never have an issue like that with a self-written CMS.
You’ll also never have to think about licensing or copyright. Once I’ve got my CMS I can do what I like with it, never having to think about whether this or that use is restricted. And who knows, maybe one day I’ll even have a saleable product!
The Drawbacks of Writing Your Own
There’s a flip-side to the security benefit I mentioned a moment ago, which is that a self-written CMS can still be the victim of a security exploit, in fact it’s more likely to be. More likely because the major cause of all security flaws is programming errors. There might be bugs in my code that expose security holes, and I don’t have the benefit of a community of people looking over the code, making improvements, helping to isolate and remove such potential problems.
Community in general is a very strong reason to favour an existing CMS. Whatever I want my CMS to do, I’ll have to write myself, and there might come a time when that in itself becomes a practical issue. Maybe I just won’t have the time to add the feature I need, something I could have solved in half a day with a WordPress plugin.
Even a simple CMS takes a very long time to build. I knew it would never be a trivial task, but I didn’t predict at the start just how much of my time would be spent writing admin functions. With hindsight, it should have been obvious, that building the admin tools would be (and was) about 90% of the work. On and off, this system has taken me half the year to develop, and I’d be lying if I said I was thoroughly motivated for all that time!
And because of that, and also as a result of the emphasis I placed on client-side output, some of my server-side admin processes are incredibly obtuse. This doesn’t affect the users of course — when it comes to actual page views, I’ve made those processes as slick and efficient as possible. But some of the admin functionality is slow, inelegant code, that I didn’t enjoy writing and just wanted to be done. If I were actually releasing this code for other people to use, I would never accept it. It’s only because it’s just for me, and only actually affects me, that I can choose to ignore such things.
When all is said and done, the main reason I chose to write my own CMS is because I wanted to. The main benefit is that it’s precisely what I need, and the main drawback is that it took ages to build.
Looking at that in a task-focused way, it simply wasn’t a cost-effective and efficient use of my time, and if my original thinking had been driven by the needs of a client, I would never have made this choice. It’s probably only because it was just for me, that I had the freedom to write my own CMS.
But then, there’s an adage in software development, that
the best ideas are the ones which solve your own problems, and most of the scripts and tools I’ve written — and all of the most successful — have started from exactly this premise.
If you enjoyed reading this post, you’ll love Learnable; the place to learn fresh skills and techniques from the masters. Members get instant access to all of SitePoint’s ebooks and interactive online courses, like The Beginner’s Guide to Web Design with WordPress.
Thumbnail credit: Mike Procario
- 1 KeystoneJS: The Best Node.js Alternative to WordPress
- 2 Off With Your Head! Build Better Web Apps with a Headless CMS
- 3 Getting Started with Sulu CMS on Vagrant The Right Way™
- 4 Sourcehunt 2016.8 - Contribute to Regression, Regex, ORMs, and More
- 5 WordPress: A World-Class Content Management System