Content Management Systems (CMSs) have one job and one job only, they manage content. Most will do many jobs on top and some of these extras might be reason enough to choose them over a fully featured CMS. For example, a CMS might be great with ecommerce, but not allow your to create multiple types of content or might have a great frontend or the cost might be low. Choosing a CMS for specific reasons is fine, but in most cases one extra feature, when other features are missing is not a good reason to choose software.
Features
Before we dive into outlying features, let’s look at all the features your CMS should have out of the box. Below is a list of features a CMS should have:
- Secure admin login
- Create, Read, Update and Delete pages
- Page Types - Article, Page, Product, Service, etc.
- Additional page fields (Subtitle, Secondary body text, Link list, etc.)
- Additional hidden fields e.g. meta description
- WYSIWYG (What You See Is What You Get) to format text
- Un/Publish
- Scheduling - Auto un/publish
- Menu system
- View/Group system
- Search, filter & sort
- Pagination
- Translation
Extras a CMS should probably have, but may not:
- Backup
- Revisions
- Other workflows than publish and unpublish
- Soft Delete
- Commenting
- None-admin login / register
- Taxonomy – Types for filtering and grouping e.g. Mouse is in the Taxonomy type Animal and Mammal, but not in Fish.
- Modules
As you can see from the above lists, a CMS has many features, some you will need right away, others you might not use for a while or not even notice until you need them. Let’s have a look at a few of these features in more detail.
Secure login
Only some users should have the ability to manage content and only some people should have the ability to comment. The CMS should have a secure system to manage accounts, for example below are some types of user we may see:
- Admin – Can do anything on the system
- Editor – Can create, update, or delete content, but can they do this for all content or only their own? Can they completely delete content or only soft delete?
- User – Can comment on content or reply to other content. Does this need an account or should anyone have this ability?
Depending on the type of website or app, the type of users may change. For a basic 3 page site we may only need 1 type of user, Admin, but in a site with thousands of products and hundreds of Articles we may need to create different types of user so type deals only with their given domain or specialty (or multiple specialities).
A username and password is all that is needed on most CMSs, but some may have the ability to add 2 factor authentication via an app, text, email, etc.
There may be other secure limiting factors, for example a user might not even see the CMS unless they are on the same network, but that would be configured outside the CMS, and is usually done via network operations.
Pages
If a user can create a page, then manage that page, what else can they change? They may need to add in a meta description for SEO, or a Subtitle for the design and would there be a separate design for each page or each type of page? If there is a subheading for one type of page, we may see it on other page types, but it might look different.
On this website we have 6 types of page, including Article (this type) which has a different design and wireframe to the Knowledge Base type, so Article needs different fields than Knowledge Base. Below are the fields for 2 of the page types on this site:
| Article page type fields | Knowledge Base page type fields |
|---|---|
|
|
The main fields of the page types are similar, but you’ll notice Article has fields like Comment settings and scheduling which the Knowledge Base does not have. Knowledge Base has a second content which appears in the design after the main content (different design for mobile and desktop).
Also, all Knowledge Base pages appear in the Main Menu and in the section for the knowledge Base, the Articles will appear in the Articles section and Articles have a filter for the different types, knowledge Base has no such filter because there are no types of Knowledge Base. The CMS allows us to configure all of this from the admin side.
Things get particularly interesting when a page needs a certain type of field that fits a niche and that is not a usual field. Most people that have a CMS will want a page with body text they can configure with a WYSIWYG, but most people will not want to add a link to an API, from a 3rd party, that renders the content from the link added e.g. a map using Google Maps. Some CMSs will allow us to add these in using the Admin system or with some code using Modules (see modules later).
Once a page is created, we may want to translate the page into multiple languages. The CMS should have the ability to:
- Add translations for the pages
- Add translations for the user interface like buttons and forms
- Allow the visitor to change language to see the translated content
Most sites won’t need this, and Google translate or other browser translation will do, but for larger sites that sell to different countries, the ability to download all content to a file, send to a translation company and re-upload with the new translations is crucial.
Menu system
If we have a bunch of pages we’ll need to allow our visitors to navigate them in a logical manner. For this we will create a main menu, but we may need submenus or menus outside the main menu for example a footer menu.
For this site we have a main menu, with submenus for Services, Knowledge Base and Projects. We then have a menu for the Footer. Some of these are automated for example, as we create new Service Pages, the page will create a new menu item in the services menu. Some menus are manual like the Footer menu items that we manually add in. Some menus are reused, like the Services submenu is under the services link in the main menu and in the footer menu.
Views & Groups
Views are an interesting aspect to the CMS and can be closely related to the Menu system or Taxonomy or views can be a separate system altogether.
We may create a view that will group all service type pages and show the title, main image, summary, and link to read more. This may be paginated so we only see the first 10 or so, then load more as we scroll down or hit next. We can then take this view and create a menu from it and show only the titles and links for a menu or we can create a menu for it using a the menu system.
Depending on the view we create, we can change the look from showing cards to a table view, and we may even have a button to allow the user to change this. We can then filter the pages further; we may have a level for each of the services, gold, silver or bronze, and we can add a filter that we can allow visitors to change the type of service shown or we may add in a secondary navigation to change this.
We can add a time it takes to complete each service and allow the visitor to sort by that number or by title or whatever they choose.
Search
Very simple to define, but difficult to create and keep up-to-date with reindexing (making sure new content is searched). A CMS should come with some sort of search, but the more feature rich CMSs will come with more nuanced searches, for example within a type of page only or show all results until the visitor starts to type so they don’t have a blank page.
There are also indexing options to think of. Indexing can take a lot of resources on a busy site, so should it happen on publishing each new page or once a day when the site is less busy? If only periodically, then searches will not show new content until the re-indexing happens.
Backup
There are multiple types of backup, from full database backup and restore to revisions of pages. Most CMSs will come with something for backing and restoring data, and it is advised you understand and test this on a regular basis, because when the time comes, and you need the functionality, you do not want to find it was switched off months ago.
The most simple type of backup is the content revision. Every time any content is updated it is not overwritten, but a new version is created, so at any point you can ‘roll back’ to an older version. This ties in with the ‘soft delete’ functionality where content is never deleted, only ‘not shown’ in most situations.
The full backup or database backup will take a snapshot of the system as it is at that point and if something goes wrong e.g. someone wipes the production database instead of the local database (oops) you can always restore.
Modules
This is functionality the CMS does not have when first created, but can be added in later as needed. Some CMSs allow a user to browse modules, click a link and have the module installed. Some need a download and upload to the system, but whatever the pathway to installing modules they can, and do, destroy systems.
A module is usually code and database changes that are added to a system and installed to run the changes. They can add in new fields for content or updated translations or a plethora of other minor and major system changes.
Each module installed can slow a system and can be a security nightmare or can simply break the system so care must be taken when installing a module or even creating a module. It is best to do a full backup before adding any module, and if possible, a check the code to see what it is doing. Most modules add functionality that makes the system ‘better’ in some way, but it is always best to be ready to re-deploy from backup as it is possible for a module to open up security vulnerabilities, change prices throughout the system or slow a system until it becomes unusable.
Frontend
I’ve left this section until the end for good reason. The Frontend is the part of the system that is shown to the visitor, it is separate from the management or administration of content. Remember at the beginning of this Article I said:
Content Management Systems (CMSs) have one job and one job only, they manage content.
This means a great CMS should not have the job of showing content at all. A CMS manages content, it does not render pages or route a visitor to the correct place. If it does, then it is doing more than 1 job and the CMS might be all the lesser for it. A CMS might be great at managing content but not good at the showing the content, does that mean it is suddenly a bad CMS? No, but by doing an unsatisfactory job at showing content it might suddenly feel like a bad CMS.
Now this is a very narrow view, in reality most people will expect a CMS to allow a view of the content that has been created and will expect that view to be useful. So, most CMSs come with a Frontend that is perfectly acceptable and, in most cases, exactly what we are looking for, and because of the integration between the CMS and the Frontend we can expect the two parts to work well together and include functionality we might not expect if the two parts are split, like edit in place.
If the Frontend from the CMS is used we can expect everything from the management side to perfectly gel with the Frontend so visitors can see pages, sections, search, blocks showing the featured pages, language switches, filters, sorts and everything else you can configure in the CMS. As an added bonus we can purchase Themes that we can install like modules, make some changes and we have a website or app ready to go.
Unfortunately, there is a ‘but’ here. A CMS is created to manage data, and because that is its job, its architecture is built to do that job, and that makes it slow to show the content. If we use Lighthouse (Googles performance indicator) and we check the speed of a site, we get a number from 0 to 100. Most CMS sites perform between 60-80 (Shopify and WordPress coming in at around 70, Drupal around 80) but a good Frontend website comes in between 90-99 (Huyton Web Services website is around 95 and when we look into performance, we should get that higher).
Finishing remarks
If you’re looking to create a CMS or pick one for your website or app (there are literally hundreds out there to choose from) you’ll want to look at the functionality and any specialist functionality you need. Some CMSs are paid for, and you install on a server, some are paid per month, some open source, some come with hosting, some you’ll need to host yourself.
In the coming weeks I’ll create an article listing some CMSs and choosing the correct one for different jobs, but if you have any experience with any CMSs (good or bad) please comment and let me know.