Understanding content models
Last updated
Last updated
Rangle.io
You need to structure and store CMS content in a way that makes sense for content authors. A CMS is essentially a database with a GUI for authors to enter data. How you conceptualize content directly impacts how your content authors can use your platform.
Furthermore, your content structure is critical to your headless platform's overall system architecture. Contentful, Sanity, Stackbit, and others provide suggestions for content modelling, complete with their own platform-specific terminology. Strapi has an opinionated content model, which means your developers don't have to figure out how to structure your content data; however, this also means you have limited flexibility and control over the UI/UX of the platform.
Contentful provides a GUI for creating a content model, allowing the developer to name the content model, as well as provide different types of fields directly from the Contentful website. These fields make up the UI that the content authors will use.
Each headless CMS tool will have its own unique way for developers to create content models.
Although headless CMS tools do not distinguish between different kinds of content models and their use cases, we have found that all headless CMS platforms require different “types” of content models. While these are concepts that we've created, they are very fundamental concepts to understand and they typically follow the same structure regardless of the project.
We group similarly structured content with a shared purpose into content models (also known as schemas). There are three types of content models: pages, page modules, and data objects.
Purpose
Dictates the layout of a page
Is the content that website visitors see on a page
Passed as a JSON object or other data
When building a page
Maps to a page template
Maps to a component in the component library
Not rendered as a React component
A page is a content model that mirrors the information needed to put together a single page. It usually contains two different types of content:
Metadata
URL of the page
SEO-related content such as title, meta description, meta image
Page layout
Content that is rendered on the page
Order of the components on the page
You can create multiple-page content models depending on the needs of the website. In the past, we have created separate content models for templated pages and non-templated pages to capture different layout requirements for these two distinct pages. In a templated page, the components are hard coded, and authors can't change the layout of the page. In a non-templated page, authors can add and move content around and change the page layout.
You can read more about how this content model is used when building the site in Connecting content data to front-end components.
A page module is what's displayed on the page. This content model mirrors the information needed for a single component we want to display on a page. Content authors add page modules to a page and enter data in input fields within the CMS.
A page module maps 1:1 to a visual component on the page; it has counterparts in the design system and component library. When building a page, a JSON file is passed as props in a component, and the page module becomes a component.
A data object exists independently of any page or page module. This content model is for content that is not tied to any visual aspects of the website or needs to be used to render visuals that vary by context. In those cases, it doesn’t make sense to couple it to a single page or component, and instead, we use content models to store a group of content as raw data. This is similar to the use case of a classic database.
A blog author is a good example of this type of content model where we can group all of the authors’ information into the content model, but it isn’t directly connected to a single page or component. We could imagine the author content model being referenced in different blog pages or used to filter blogs in a search functionality. Other examples include redirects and SEO data to be passed to search engines.
A data object is rendered as a JSON object, not a React component, as it doesn't directly tie to anything that's visually displayed.
