selecting a Content Management System (CMS) – the importance of the back end. part 2

In part one of this post I looked at some logical starting points for choosing the right content management system (CMS) for managing the content displayed by your web applications, as well as what factors might determine your choice - many of which are based around getting the right tool set.

In this post I look at how the questions we ask in determining the right content management tools panned out for three of our clients. I also look at some of the common things that can go wrong over time once you're live with your new CMS, as well as how these issues can be mitigated.

Travel Nation

Travel Nation wanted to move from an environment where too few content managers acted as bottlenecks to the various people who needed content to be put on site. This process of democratising content updating to resolve this meant that the tools needed to be as simple as possible. The process focused on inbuilt validation to ensure accurate completion and categorisation of all content before it was published. The same taxonomies which are used to categorise content are also used to manage images, which makes applying effective pictures to content is a quicker task than it was before, with end results being more relevant, and therefore of higher quality.

The Student Room (TSR)

For The Student Room (TSR) it’s not just the content managers that need the ability to edit content. Community members and TSR clients can also create content, with the type of content they can create governed by their permissions (which in the case of TSR clients is determined by how much they pay) This meant three things were key:

  1. Content needed to be creatable and editable from the front-end for TSR users and clients.
  2. This User generated content (UGC) needed to be moderated by internal content staff before new articles or edited articles could go live. Content managers needed the ability to be able to add comments to reviews, as well as override changes or locks on content if requests were not followed up on.
  3. Contextual and inline help, as well as data validation and spam prevention measures had to be built in on the assumption that if it could go wrong, it would go wrong.

NHS Brighton and Hove

Many different types of staff make up a local NHS organisation, so different departments have different levels of content requirements. Secretaries to board members, for example, should be able to edit agendas, meeting dates and upload board papers, but should not be able to create or edit content, or upload documents in the prescribing section of the site for GPs.

Content quality and accuracy is absolutely key for NHS, so all content has a review date set, with authors notified by email in advance of these. The overall site manager can also pull a report of where progress is against review dates, so that they have the data with which they can chase up those who are running behind.

what makes all of this achievable?

The common feature with all the three sites above is that they were built in Drupal. Drupal allows developers such as ourselves to:

  1. Create specific content types for each distinct part of content.
  2. Create multiple taxonomies to categorise the content and determine who can use, edit or create terms within these.
  3. Create multiple roles (e.g. admin, senior editor, junior editor etc.) and decide what permissions to assign to this on a function-by-function and content-by-content type basis. By restricting what users can see (and, as importantly what they can’t) the back end can be made as concise as it needs to be.
  4. Create specific templates and themes for the back end and the means within this to display editable content based on various criteria, making it easy for content managers to get a holistic view of content within their remit.

once live, what might commonly go wrong and how is it mitigated?

These are some common issues we see arising over time.

organisations and people change

Those users who we trained on day one are different, fewer or greater in number, less or more skilled, have more or less time or have different requirements from those who are there today. Understanding and knowing your client helps with keeping up with this, as does having a support package flexible enough to adapt to change.

users delete content or people they shouldn’t

With effective control of permissions we can restrict who can delete content – and in fact ensure that, if need be, content gives the impression of being deleted when it is in fact still archived somewhere and accessible by a higher ranked role.

people find workarounds

As humans we’re pretty adept at finding clever workarounds to achieve a use of a system which wasn’t intended. This then might cause issues down the line if an organisation wishes to use that data in a different way. All we can really do in this instance is encourage clients to share these with us, as and when they start using them, so we can either be aware of the situation or determine if we need to create a specific tool to handle it.

breaking content 

Where we give certain roles the ability to add manual links, or change URLs, or delete content there’s always a danger related content can disappear, or unintentionally become unavailable to certain user groups. When this happens it’s often an indication of where permissions may need to be tightened up, or validation or checks improved. 

general technology changes

Google search algorithm changes and evolving best practice in terms of managing or optimising content for mobile devices are two examples of where technology might change how certain content is managed. The way in which images are handled is often a good example. Hi-res screens have meant that often we need better quality images to make pages look good on the latest devices, while at the same time recognising that fast internet download speeds are not a given everywhere.

improvements in feature sets or the CMS tool set

Most of the sites we build change over time. Each time we add new functionality we’re generally augmenting the tools that provide this, but it is not always a given that the way in which training or documentation is updated to cover that will be as uniform as when the solution was first rolled out – especially if support time is at a premium. Sometimes the changes may come about due to small changes in how updates to the CMS impacts how the tools are used. These sorts of changes, and indeed any small iterative changes, can make it harder to keep training and documentation updated.


The more tailored the back end is to your specific team’s requirements and skills and the more flexible it is to meet the changing demands of your business, the better and more future proof it will be. Drupal is unique in all of the CMSs we have used in that we have yet to find an example where the requirements of a business have outstripped how Drupal can manage them in the back end.

If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.