Traditional websites were bespoke creations: a freelancer or team of web developers built a site and handed it over, with the content essentially frozen in carbonite. Any changes to the site required communication with the developer, who functioned as a kind of gatekeeper.

Quite reasonably, clients wanted the ability to edit the content of their own sites, without having to learn HTML or CSS. At the same time, developers wanted a system that they could use to develop sites faster, rather than building each one as a unique creation. Content Management Systems are an answer to both problems.

Broadly speaking, Content Management Systems (CMS’s) organize a site’s data (page text, images, etc) into modifiable components. Typically, this content is stored in a database. When a page is requested the data is pulled in with other components, such as headers, page navigation, CSS, etc, to form a complete page. This allows site stakeholders to modify, add and remove content without needing to know any HTML or CSS.

There are now hundreds of CMS’s, covering dozens of different purposes. Before choosing to develop a site with a CMS, it’s important to understand a set of issues that every one of them carries:

Intended purpose

A Content Management System, like all software, is born with a particular purpose: to be a blogging platform, ecommerce system, etc. As it grows and matures, there is a tendency to make software all things to all people, blurring its original vision and complicating the codebase. At the same time, every CMS will continue to carry the inheritance of its original software “DNA”, inevitably creating a situation in which the developer is struggling to install an online chat system plugin in software originally designed to sell scarves.

As a general rule, you’ll tend to find your work produces the best results in software designed for an express purpose, rather than as an add-on. WordPress was originally intended as a blogging platform; Magento is an eCommerce suite, moodle is designed to make education sites, Koken for portfolios, PHP Nuke for forums, etc. That doesn’t mean that you can’t use a CMS in ways other than its intended purpose, only that you may find yourself fighting against the natural current of the software.

Security

As soon as you make a website editable, you make it vulnerable. Popular CMS’s present a large attack surface: a vulnerability found in the software potentially makes all installations of that platform open to attack. CMS’s are not “set and forget” – they must be maintained and updated like all software.

Content and Code Editing

Some CMS’s, such as SharePoint, are notoriously “locked down”, making it very difficult to edit HTML, CSS or JavaScript at the code level. Others, like Drupal, take the opposite approach, and present themselves as so “open” that every switch and option is immediately available, which can be somewhat overwhelming. The perfect solution will depend on the client’s needs and abilities together with your own workflow and process.

Responsive / Mobile Support

Most CMS’s now boast some form of support for responsive design at the pubic-facing end, but not all. Researching a CMS’s support for mobile is important.

It should also be noted that little mobile support is usually provided at the actual data-entry level. If it’s likely that you’ll be making changes to the site on the go from a mobile device – as more of us will be – this is an important consideration. A few CMS’s, such as Craft and Ghost, are leading the way in this regard.

Data Adaptability

Can I use the records in a particular CMS to auto-generate Facebook and Twitter posts together with an RSS feed, each of which have their own particular restrictions? Can I rebuild pages in different languages, without having to make a new site? Can I filter site content not just by when it was made, but by the geographical origin of posts?

These questions are closely tied to how a CMS stores information for a site: broadly speaking, a CMS that “chunks” content into discrete components and has strong support for metadata will be more adaptive that one that does not.

Support

As soon as you employ a CMS you become tool-dependent. That’s not necessarily a bad thing, but it does mean that you need to know where questions can be answered and when and how bugs can be fixed. A lot of CMS software is built under an open-source model, which often means that patches are released quickly but documentation quality and UI suffers.

Responsibility

Less an issue of the CMS is how a company approaches the possibilities that the software allows. Making the site editable by company employees is a powerful tool, but one that is open to misuse and error. The traditional advantage of having a site developer act as a gatekeeper is that they could function as a quality control filter and user advocate, translating requested changes into something appropriate for the web. Providing direct access to a site can open up a world of hurt, from CEO’s weekend design changes to misleading information entered into pages. Choosing what site features to give access to whom is a very important question.

This provides an introduction and selection criteria for Content Management Systems; next, I’ll look at the kinds of CMS’s available, and the different ways they approach site creation.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.