A content management system can represent articles, people, topics, and media as structured records. Content modeling describes those records, their properties, and their connections rather than the final arrangement of a web page. The same editorial subject can therefore be discussed as stored data without deciding how a website should look. This guide defines types, collections, fields, records, and references using official Drupal and Sanity documentation. Platform vocabulary is attributed rather than treated as universal. A hypothetical article-author-topic library illustrates the concepts; it is not a client implementation. The scope is content structure, not platform selection, implementation architecture, navigation planning, or purchasing a service.
A content model and its component types
A content model describes the kinds of content represented, the properties available on each kind, and connections between records. Drupal illustrates the structural distinction through entities, entity types, and subtypes. Its content items belong to content types, while other entity types include user profiles, files, and taxonomy terms. These are specific Drupal terms, not interchangeable names for every CMS concept. Drupal: Concept: Content Entities and Fields
In the hypothetical library used here, Article, Author, and Topic name three kinds of record. Article defines title and body fields; Author defines name and biography fields; Topic defines label and description fields. These definitions are structures, not populated articles or people. Drupal similarly explains that entities of a given subtype have the same collection of fields available, while editing an entity supplies values for those fields. Drupal: Concept: Content Entities and Fields
Collections, entries, and items
A collection, in the generic vocabulary used here, is a grouping of similarly structured records. An item, entry, or document usually refers to an individual record, but those words need platform context. Drupal calls an individual item of content data a content entity; Sanity describes references between documents. Neither source establishes “Collection” as a universal technical name across CMS products. Drupal: Concept: Content Entities and Fields Sanity: Reference
The useful distinction is between structure and instance: Article is the hypothetical structure, while “Understanding image dimensions” is one article record. A group of article records is not the same thing as a visible list on a page. Drupal’s view-mode documentation separately describes display contexts such as full pages and teasers, illustrating why stored content and its displayed form should not be conflated. Drupal: Concept: View Modes and Formatters
Fields, data types, and validation
A field holds a particular kind of data. Drupal documents formatted text, plain text, images, other files, and dates as examples. Different content types can expose different sets of fields: a basic page might have title and body, while another type also has an image and website address. A field definition and an individual record’s field value are therefore different things. Drupal: Concept: Content Entities and Fields
Validation adds rules about acceptable values rather than merely naming a field. Sanity’s reference documentation distinguishes the stored field name, its human-readable title, its editorial description, and its allowed target document types. It also documents required validation, which ensures the field exists. A label, explanatory text, permitted target type, and required-value rule serve different purposes even when an editor encounters them together. Sanity: Reference
References and linked records
A reference identifies another record instead of simply repeating one of its text values. Sanity’s reference example stores a reference object containing a document identifier in `_ref`. In the hypothetical library, an article’s author reference therefore identifies an Author record; an author-name text field would instead contain characters. Two authors with identical names could still be distinct records. Sanity: Reference
Reference behavior also includes platform-specific integrity rules. Sanity documents strong references as the default: they require the target document to exist and prevent deletion while another document refers to it. Weak references can point to missing or deleted documents. These rules concern the relationship’s integrity; they do not establish that copied text, exported files, or external caches automatically change when the target record changes. Sanity: Reference
Relationship cardinality and direction
Cardinality describes how many records a relationship can connect. A single author reference allows an article to identify one author; an array of topic references can identify several topics. Sanity explicitly documents references for document relationships and arrays of references for one-to-many relations. Whether a reference is required is a separate question from whether it permits one target or multiple targets. Sanity: Reference
In the hypothetical library, several articles may point to the same Author record. That is many-to-one from articles to author, or one-to-many viewed from the author side. If each article can reference several topics and each topic can be referenced by several articles, the conceptual relationship is many-to-many. The stored direction remains separate: Article-to-Author does not itself create an editable articles field on Author.
A hypothetical editorial content structure
Consider this illustrative structure: Article contains title, slug, summary, body, author reference, and topic references. Author contains name and biography. Topic contains label and description. An Article record titled “Understanding image dimensions” points to an Author record named “Example Editor” and Topic records labelled “Images” and “Specifications.” All names are fictional and demonstrate relationships only; no publication workflow or live site is implied.
Here, title and summary are text values, body contains formatted content, author identifies one record, and topics contains multiple references. The model separates an article’s own values from connected records. Drupal documents text and formatted-text fields, while Sanity documents references and reference arrays. Exact field identifiers, rich-text representation, and validation settings remain platform-specific. The example does not imply that a slug is automatically unique or automatically becomes a public URL. Drupal: Concept: Content Entities and Fields Sanity: Reference
Stored structure and rendered presentation
Stored structure and rendered presentation answer different questions. Drupal calls the context in which an entity is displayed a view mode, with examples including a full page and a teaser. Within each mode, fields can be shown or hidden and assigned formatters. A formatter controls how a value appears, such as trimmed versus full-length text, rather than defining a new underlying content type. Drupal: Concept: View Modes and Formatters
Consequently, the hypothetical article could retain the same title, author connection, and topic references while appearing differently in a full view and a short listing. Drupal also documents taxonomy references displayed either as plain text or as links, showing that a stored relationship does not prescribe one visual treatment. These distinctions explain modeling terminology; they do not recommend a CMS, define website navigation, or establish a platform migration strategy. Drupal: Concept: View Modes and Formatters
Frequently asked questions
Is a content type the same as a content entry?
No. A type describes the available structure; an entry is an individual record. Drupal describes content types as subtypes of content items and explains that editing entities supplies their field values. Drupal: Concept: Content Entities and Fields
Are CMS fields the same as page elements?
No. Fields store data, while display settings determine how values appear. Drupal separates entity fields from view modes and field formatters, including whether fields are visible in a particular display context. Drupal: Concept: Content Entities and Fields Drupal: Concept: View Modes and Formatters
How does a reference differ from plain text?
A reference identifies another record. Sanity’s example uses a reference object with a target document identifier. A text value containing an author’s name does not by itself establish that document relationship. Sanity: Reference
What does a multi-reference field contain?
Generically, it contains multiple record references rather than one. Sanity documents an array of references for this purpose. The exact field name and stored representation depend on the CMS, so “multi-reference” is not a universal API type. Sanity: Reference
Does a content model define the website’s navigation?
Not by itself. The hypothetical model stores article, author, and topic relationships, but it does not specify menus, routes, ordering, or user journeys. Those questions are separate from the record structures explained here.