Structured content
How Visual Editor works with structured content, along with content modeling basics.
Visual Editor sites rely on structured content that can drive both the presentation and behavior of your site, an approach we call content-driven development. This guide explores how Visual Editor works with structured content in content-driven sites.
# Content requirements
Visual Editor’s only real requirement that affects your site's code is that content must be structured and separated from code.
For a page to be editable in Visual Editor, its content must be represented by a structured data object coming from a content source. This type of object is referred to as a document. For components to be editable, they must also be represented by structured content, either as their own document or embedded inside another document (more on this below).
Documents of a similar structure are grouped together in the content source using a model. In other words, we can say that every editable page and component is represented by a model in your content source.
# Types of models
Visual Editor uses three types of models:
- Page: That which represents the shape of a page, as mentioned above. Example: A blog site that uses a
Postmodel for its individual blog posts. - Data: Content objects which are meant either to stand alone and be accessed globally, or to be referenced from a page. Global example: A
Headermodel that contains content for a site's main menu. Reference example: A blog site uses anAuthormodel to apply rich attributes toPostcontent (via a reference field). - Object: Repeatable content that is embedded in another model (of any type). Component models are typically object models. See the composable page section below for a detailed example.
Here's an example of how elements on a web page may be modeled:
- The header and footer content comes from globally-shared content objects of a
datamodel. - The content specific to the page is wrapped in a
pageobject. - Content for components within that page are of the
objecttype, and are embedded within the page object.
# Content modeling for headless CMS
Visual Editor automatically inherits the schema (collection of models) from the API CMS.
However, because most API content management systems don't have the concept of pages, page models must be extended with Visual Editor-specific attributes by setting type, which is often handled by extending page models.
See modelExtensions property reference
# Distinguish model types
Whether Visual Editor can resolve the distinction between the data and object type for the remaining (non-page) models depends on the behavior of the CMS.
# Contentful example
Contentful has no concept of model types. Everything is an entry. Therefore, all non-page models from Contentful are assumed to be data models.
Learn more about using Contentful as a content source.
# Sanity example
Because Sanity has the concept of documents and objects, all documents that aren't pages become data in Visual Editor, while Sanity objects remain object models in Visual Editor.
Learn more about using Sanity as a content source.
# Content modeling for Git CMS
When using Git CMS as the content source (files in the repository), you may not have any concept of modeling, as you can technically use files as a content source without any sort of schema.
Visual Editor requires that all content objects be defined by some model. Therefore, file-based content must be represented by the models property in the Git CMS content source configuration.
See the content modeling reference
Did you find this doc useful?
Your feedback helps us improve our docs.