As everyone knows, a CMS or Content Management System is a handy thing to have. They can vary wildly in form and function but their basic core function is to allow easy updating of a website, usually by non-technical resources.
When CMSs first started, they were generally single function tools, designed to edit one aspect of the website. More often than not, they were custom built for the particular site on which they were used. I built a CMS back in 1995 for Coca-Cola’s first site. I wrote a series of content management tools in Perl using key-value hashes and associative arrays to store the data on the server. Very old skool and not terribly scalable or secure but those things weren’t on our radar as much back then.
Fast forward to now and you’ve got a supermarket full of CMSs in all different shapes and sizes. Popular examples include WordPress, Drupal, MODX, Kentico, DotNetNuke, ProcessWire, Kirby, the list goes on. They all have various strengths and weaknesses but they all allow you to update a website through a browser-based interface.
Using a CMS isn’t always a forgone conclusion, however. Over the next few sections we’ll explore some of the things that you should keep in mind when you are deciding whether to use a CMS.
What Kind of Site Is It?
Is your site a standard brochure-type site with content about your company: news, blogs and other variable content? If so, a CMS makes sense. Or is your site a tool, designed to perform a function or provide specific interactivity? Once built, this site might need minor, infrequent or no content updates at all. In this case, a CMS would be unnecessary or perhaps even detrimental to the function of your site.
Who’s Updating the Site?
Another consideration, obviously, is to take a look at who will be maintaining the site. If they’re not technical then a CMS usually makes the most sense. Most CMSs can be used quite effectively without any knowledge of coding or the inner workings of the web. Most of our clients are self-sufficient with just a little training.
The volatility of the content should also be taken into account. Is the site going to change daily, weekly, etc? More frequent updates might necessitate a CMS. Many systems have workflows built in for managing content updates and approvals. If you feel you need to tightly manage content updates and have comprehensive checks and balances in place to ensure that all updates are tracked and approved, then a CMS might give you the structure you need.
The features of a CMS usually come at a price in terms of performance. Many CMSs have caching and various parameters that can be tuned to achieve better performance but at the end of the day, there’s still overhead when compared to a non-CMS site. We do a fair amount of promotional-type ecommerce, situations that can result in booking thousands of orders in a matter of hours or even minutes. In these situations, we can’t afford the overhead of a CMS so we build a static site that’s load-balanced across multiple servers.
As a general rule, and I do mean general, non-CMS sites tend to be more secure than CMS sites. The reasons are two-fold. One, a non-CMS site tends to be simpler. Simpler means easier to troubleshoot and avoid common security issues. The less code, the less of an opportunity there is for unintended consequences.
Second, the more popular a CMS, the more nefarious individuals you have taking the time to suss out exploits and weaknesses. Their logic is that if they crack a popular CMS, they’ll have many more sites to leverage their hard-won exploit on. An exploit on a scratch-built site might not be applicable to any other site on the web. For the most part, cracking a site takes a lot of time and hackers, like everyone else, want to get the most bang for their effort.
Take WordPress for example. Exploits, cracks and hacks are rampant on the WordPress platform. 99% of all security issues we have are on this platform. And the biggest driver for this is WordPress’s popularity. That and Wild, Wild West plugin library. Find yourself a nice exploit on the platform and you’ve got literally millions of sites on which you can inflict it.
If we have a project to build a site, even a content-rich site, where we know that we’ll be doing all of the content updates, then we may opt to not use a CMS. Instead we’ll leverage a lot of the same tools that we use to manage our source code. We’ll also use the same server arrangements, namely a dev-stage-prod scenario.
Code and content is checked into our source code control system, like Git or SVN. Using the features of these tools, we’ll prepare or updates on the dev server, review them on the stage server and push them live to them production server. The tools keep track of all the changes, nothing gets lost and the process is very consistent and secure. Of course, making content updates is akin to coding in this situation, usually requiring a developer. But you end up with a very clean process and a super-fast and lightweight website.
So while the vast majority of our content-rich websites use a CMS, it isn’t always the best solution for every situation. There are alternatives that can better position you and your site for security, performance and management considerations.
"to Drupal or not" (cropped) by Dave O. (Creative Commons Attribution-ShareAlike 2.0 Generic)