The main reason why CMS’s were developed in the first place was the separation of the data from it’s presentation. When web sites were still a collection of static HTML files, the content was mixed up with the presentational HTML code and even with styling information. This presented problems if you ever wanted to modify how the content was displayed. If you wanted to make a simple change to the layout, you had to do the same change to tens or hundreds of files which was error prone and slow.
With content management systems the content of the pages is stored in a database and when displayed to the end user, it’s merged with a page template to produce the final web page. This separation of concerns makes content management systems powerful and easy to use for content editors.
Still, too often content in a content management system is thought as one big WYSIWYG field where end user enters all the data. This might stem from the time of blogging engines such as WordPress. Unfortunately, this causes the same problems as with static HTML sites in the past: rather than structured, the content is mixed up with HTML markup. Luckily modern CMS’s provide some really complex and convenient ways of modeling the data to separate it from the markup. Let’s look into custom content types and custom fields.
Custom content types
To begin modeling richer content, try to think about content in more abstract terms. Rather than working within the confines of the concepts of HTML page with a title, URL and content field, think about content in terms of business entities. If your web site lists events, for example, you should separate the information about the event into its own content type called Events with its own fields.
In addition to simply having a title and description, your event probably has a date and location. Instead of embedding this data to the markup of the page body, separate it into its own fields. If you do object-oriented programming, this should be familiar to you. You can think of custom content types as classes with their own properties as fields. When you create a new event in your CMS, you are creating a new object that is an instance of the event class.
Separating content types and data from markup like this is better because it allows you to enforce consistent styling in the front-end template and validate the inputs for correctness. It also allows you to query the content more effectively. Want to list the next three upcoming events on your front page? It’s just a query away. If that data was unstructured in an HTML field, this wouldn’t be possible. The content is also more portable: because the data is not tied to the presentation, you can easily modify and update the templates later on or even move the content over to a different content management system without any problem.
Most CMS’s from WordPress to Episerver and Drupal support custom content types out of the box, just consult your CMS’s documentation. Custom field support is more uneven. While Episerver and Drupal are built on custom fields, for WordPress you need to install a plugin to get this functionality. I recommend Advanced Custom Fields.
Common field types
The available field types differ depending on the CMS you are using. Some of the most basic ones are text fields, text areas, and images but there many really specific ones such as URLs, email addresses and geo coordinates. You should always pick the one that is the most specific, this way you get most out of the validation, and the user interface widget is the most appropriate for the content; for example, a date picker for a date field.
Sometimes it’s useful to have multiple values for a field, for example, your event could have multiple images. This is where lists or arrays come in handy. It’s also possible to add components or objects into a content type. For example, if your page has a button with text, a link, and a button color, you can logically group these into one entity. More about this later on.
There is really no limit on what kinds of fields you can have. Many CMS’s come with a dozen or so built in fields, but you can almost always download some more as part of a plugin or extension for your CMS. Can’t find one you need? Need a custom select box powered by your internal REST API? It’s often easy to use the API provided by the CMS and build your own field types that fit your needs.
Try to think about your end user when selecting the field you use. Let’s say you need to create a field to select a color used on the page. If your end user is not very technically inclined, it would be a good idea to provide a dropdown menu populated with pre-picked brand colors to minimize any mistakes. If your end user is very technical, you could provide a HEX input field where the user is free to select any value they desire.
Content references are a powerful feature to create relationships between your content types.
Let’s say your company organizes dozens of events a year, most of which are organized at your office. If the location details are part of the event content type, every time you create a new event, you have to type in the office location again. At this point it would make sense to extract the event location as its own content type, then you can create your office as a new location content type and in your events just reference it.
The best thing about content references is that they are easy to update. Think about blog post content type that has an author. If the blog author updates their photo or they get married and change their surname, and the data about the author is part of the blog post content, you would have to go through all of that person’s blog posts individually and change the relevant details. If you use a content reference, you would have to change the details in only one place and it will be updated automatically in all the blog posts.
Content “blocks” and components
You could think of components as content objects embedded inside a content field. Instead of referring to another content type, the data of a component lives inside the content item itself.
Let’s say you want to create add a carousel to your page. Instead of creating a new global content type called carousel slide and refer to a list those on your page, it might make sense to store the carousel slides inside the page as components. In contrast to simple fields, components are a collection of fields. A carousel component might have an image, a description and a link to another page.
By adding a new field that is a list of carousel slide components to your page, you can permit the content editor to add the slides they need directly on the content page.
In some cases, it can make sense to replace the traditional WYSIWYG content field with a list of content components. While a WYSIWYG field might serve you well for simple cases, it can grow unwieldy if the end user’s want more rich and advanced layouts.
This can manifest in surprisingly simple cases. What if your client wants to embed a video into the middle of the content area?
Manually entering HTML embed codes and adding necessary HTML wrapper elements is a non-starter for non-technical clients.
In WordPress world, shortcodes that expand a code like
[youtube https://www.youtube.com/watch?v=_Oh12ROTQCE ] might work but using them might not be straightforward for non-technical clients and they might get too complicated if there are a lot of options or fields.
By making the page content area a list of different components, we can permit the content editor to compose the page of multiple different components in a way they see fit. In the Youtube example, we might have the components the content editor can choose from, a WYSIWYG component and a youtube embed component, both with their own relevant fields.
Many “page builders” are basically an implementation of the page component pattern. These often come preloaded with a lot of different components like hero images, sliders, and forms. However, you should think about creating some custom components that fit your site requirements and design the best.
If you were a content editor editing this page...
Would you prefer this editor?
Or this one?
Minimizing mistakes for better content editor experience
Imagine browsing a website and seeing a feature on the page, but when you try to use it, it simply doesn’t work. When you report this issue to the site owner, the only advice they can give to you is “don’t do that”.
This can happen surprisingly often in CMS implementations when some options are not designed to work together or work at all. It’s easy to forget that content creators that use the CMS are end users too! When modeling content make sure you pay attention to ensuring the integrity of the content. If there is some field that is required by the site template, mark that field as required. If there are some options that do not work together, try to create constraints that prevent this from happening or at least use help text to inform the content editor about these limitations.
Many CMS’s come with a lot of built-in features that are not used, make sure they are disabled or hidden. In addition to preventing errors and broken styles, this will make the user interface a lot cleaner and less confusing for content creators. For example, if there is WYSIWYG editor that by default comes with with a lot of formatting options that are not tested on the particular site, only enable those that are actually being used.
The depth of the content modeling depends on the site you are working on. If you have just a simple brochure site with a couple of pages and a blog, the Pages + Blog combo built into many CMS’s like WordPress might serve you well. But as soon you have a more complex site with multiple page types and layouts, it helps to think about the content modeling in depth before starting to work on the site implementation.
Your future self and whoever is going to be editing content using the CMS will thank you!