Ok, peeps, time for a short break from the Sql Server kick I have been on of late. Currently, I am helping one of our daughter organizations launch their new website. A website built on rather well-designed, mature open-source CMS. And they hate significant bits of it with a passion, while not even touching many features because they are totally unnecessary in their application. Never mind the interesting set of teething issues that cropped up when the developers merged in changes from the trunk of the project over their own customizations. Their ordeal has reminded me of one thing I figured out several years back: boxed CMS applications are nightmares best side-stepped rather than embraced.
First, let me define “boxed CMS” for clarity’s sake. It is a fully-functional, feature-rich Content Management System in a box—which might be a zip file you downloaded off sourceforge. Generally featuring such things as menuing, articles, members areas, security system, RSS feeds, image galleries and forums. 95% of the time, one just need upload the files to the server, run a database script, and add content to get a fully-functioning website. The actual source—a licensed commercial application or a downloaded open-source application is immaterial. In any case, it probably has a half-dozen more features than you need.
Now, you are probably saying “Whoa, Wyatt! Why the hell would I want to build all that plumbing when I can just download it and install it and futz with some configuration settings and templates?”—a very reasonable question, deserving some very reasonable answers.
The first issue is that the very nature of a CMS is not easily boxable, without creating an application that tries to do everything for everyone and fails at doing most things particularly well. The tasks required for content management are generic, but every organization has a far different focus when it comes to how that content should be managed and how it thinks about that content. I have lost days of meetings trying to help subject matter experts understand that an article, according to this system, is really a page. Trying to make a generic application to handle this for all comers is a very, very tricky prospect.
So, the net result is that I have yet to see an end-user actually like working with an off-the-shelf/sourceforge CMS. One is invariably implementing more than a few workarounds to make, say, a blog posting system work as an article posting system. Or using a banner ad management system to handle side-bar content. Nearly invariably, one must make a compromise between good information architecture and the way the system wants to handle things. And compromising your information architecture is never, ever a good thing.
The other major issue is that I have never seen a “boxed CMS” in a production implementation limited to changing configuration settings and/or templates. There is always some, or many, requirements which pushes serious code extension and/or modification. And once you get committed to serious modifications of the system, you get into the real nightmares.
First, messing with core components can easily break other things in the CMS itself as one delves into unknown territory. But these coding issues are surmountable in most cases. It is pretty similar to most experiences diving into someone else’s codebase—rarely fun but usually workable. Unfortunately, that is not quite the end of it.
For me, the scariest part is, after one has significantly modified this application (proverbial square peg) to fit the requirements (proverbial round hole), you have a strange hybrid application. Largely legacy code, with some mission-critical custom bits. Because those custom bits are living within the legacy system, they have significant dependencies on said system. And then the controlling party of your boxed CMS —be it a vendor or the open source project—releases an update. And, more often than not, this update breaks your changes, rendering your implementation of the application useless.
Exacerbating this nightmare, for those of us responsible for the security of the boxes we control, is the fact that many of these updates contain critical security patches, often with exploits in the wild. Meaning that your customized version of this boxed CMS is now a significant security risk to the organization because you have broken the update cycle in order to fit the requirements of the application. Which is a tricky spot to be in. You are now forced to either break your website, do a rushed patch job to make your changes compatible with the new regime, or just blithely hope no one notices the security hole.
My net life lesson, after having dealt with my fair share of boxed CMS implementations, is to avoid them—unless you are clear that you will, in fact, stay within the box.
A Comparison of Ruby Version Managers for macOS
By Daniel Kehoe,
If you're a serious Ruby developer, you'll need an up-to-date version, possibly several. We cover the best Ruby version managers for macOS.
A Guide to Git Interactive Rebase, with Practical Examples
By Tobias Günther,
Even if you're a Git pro, there might be more Git tricks to discover. Learn about interactive rebase, one of Git's most powerful tools.
Introduction to Data Types: Static, Dynamic, Strong & Weak
By Tim Hurd,
Static, dynamic, strong, weak data types? Are you confused? Learn what these terms really mean, and which is best for you.