Content model review checklist
This page is for developers who review a content model, their own or a colleague's. A model is cheap to change on paper and expensive once content exists, so review it twice: before building, with an editor and a designer in the room, and before launch. Each item has the question to ask; the pages linked explain the answers.
Contents
- How to run the review
- Classes
- Identifiers and names
- Datatypes
- Relations and reuse
- The tree
- Access
- Languages
- Editorial workflow
- Presentation
- Portability
- Recording the result
How to run the review
- Bring the model as written (Designing a content model, step 8): a table per class, a sketch of the tree, the roles.
- Bring real content: three real items per class, not lorem ipsum.
- Ask an editor to "create" each item on paper with the fields given, and a designer to point at where each field appears on the page.
- Go through the lists below; every "no" is either fixed or written down as an accepted risk.
Classes
- To do: Does each class stand for one real kind of content? (No class whose "type" field changes everything.)
- To do: Are two classes that share every field really different? (If only their place differs, merge them.)
- To do: Is every container a container, and every leaf not one?
- To do: Is the object name pattern meaningful, so names in lists and URLs are recognizable? (Content classes and attributes)
Identifiers and names
- To do: Are identifiers lower case, English, and the same for the same meaning in every class (
title,intro,image)? - To do: Are project classes prefixed where they could clash with a site package's classes?
- To do: Are the human names and descriptions written for editors, translated where editors need it?
Datatypes
- To do: Does each field use the datatype that matches its meaning (dates as dates, choices as selections or tags)?
- To do: Is long text rich text, and short text plain?
- To do: Are required, searchable and translatable set on purpose for each field?
- To do: Is every extension datatype from an extension that is active on all siteaccesses that need it? (Choosing datatypes)
Relations and reuse
- To do: Is everything used in more than one place an object of its own, referenced by a relation?
- To do: Is each reference stored on one side only, with the reverse found by a fetch?
- To do: Are relation attributes limited to the classes they may point to, with a sensible default location?
- To do: Are shared images in the media library rather than copied into many fields? (Relations and embeds, Images and image aliases)
The tree
- To do: Does the tree below the root mirror the navigation editors and visitors expect?
- To do: Is each container's sort order set (priority for hand-made order, date for news)?
- To do: Will large collections stay usable (paging, dates) at the volume expected in three years?
- To do: Are second locations used only where content truly belongs in two places? (Objects, nodes and locations)
Access
- To do: Is every "only X may see or edit Y" rule expressed as a section or subtree plus a role?
- To do: Is the Anonymous role still minimal?
- To do: Are stages beyond draft and published modeled as object states, not as folders? (Sections, roles and policies)
Languages
- To do: Are the languages and the fallback order decided per siteaccess?
- To do: Are fields that must not differ per language untranslatable?
- To do: Are shared objects (folders, media, people) always available? (Translations and languages)
Editorial workflow
- To do: Is it clear who creates, approves and publishes each class, and is that a workflow or a habit?
- To do: Are dated hiding and removal configured where content expires?
- To do: Are version limits right for classes edited very often? (Workflows and triggers, Versions, drafts and publishing)
Presentation
- To do: Does each class have its view modes listed (full, line, a card, embed)?
- To do: Are pages that editors compose from blocks identified, and do they use Layouts rather than many optional fields?
- To do: Are image aliases defined for every size the design shows? (View modes, Layouts for CMS developers)
Portability
- To do: Are classes in packages in the repository?
- To do: Do code and settings refer to identifiers and remote IDs, not node or object numbers?
- To do: Do imported objects carry remote IDs from their source? (Content classes and attributes)
Recording the result
Write the date, the reviewers, the changes agreed and the accepted risks into the model document in your repository. Review again before launch with the Project launch checklist, and whenever a new class is added after launch.
Related pages
- The content model
- Mapping content to Exponential
- Content classes for builders
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.