Strapi CMS
Let's go through some of the core concepts and abstractions in Strapi.
Content Types
When working with Strapi, the first concept you’ll interact with is a Content Type. A content type represents an entity. An entity can be anything your project needs. An entity can be a post, a product, an employee, or even abstract concepts as well, such as post category.
For this project, we have the following content types — Pages, Posts, Post Categories, Color Schemes and Page Contexts.
More concretely, a content type has two parts to it:
- Schema (i.e. the structure): This is defined once, usually using Strapi’s Content Type Builder UI or programmatically through configuration files (we use the latter approach). This can thought of as the column header of a table in a spreadsheet, where each column is an attribute with a specific data type.
- Entries (i.e. the data) — This is the actual content that authors create and manage according to the schema.
Simply put: a content type encapsulates not just the blueprint, but also the content itself.
Entries/Documents
If a content type is the “header row of a table,” an individual row/entry in that table is what Strapi calls a document. But there is more to a document that goes beyond the row analogy.
Strapi uses the term "entry" on the admin dashboard, and in their documentation they use the term "document".
Both refer to the same thing.
If Post is the content type, then each blog post you create is a document, i.e. a concrete instance of the Post content type.
Document States
Documents in Strapi can have a draft–publish editorial flow, giving authors flexibility to manage content before it goes live. Documents can have multiple "versions", and can exist in multiple "states". The terms used to label a document's versions and states are similar and hence a source of confusion as to whether one is referring to a document's version or its state.
A document can have two versions (more if you factor in "locales" which we cover below) — draft and published.
And it can be in one of the following states — draft/unpublished or published
There are several combinations that the draft and published versions of a document can co-exist, let's break each scenario down:
| Action | Newly-created Document | Existing Document |
|---|---|---|
Save | A draft version is of the document is created. No published version is created. | A new draft version of the document is created. At this point, two versions of the document co-exist; one that is accessible to the public, and one that isn't. |
Publish | A published version is of the document is created (and the document is published, i.e. made accessible to the public). No draft version is created. | The existing published version of the document is discarded, and a new published version (with the latest updates) is created and takes its place. If the document had an existing draft version, that is discarded as well. |
Documents and Internationalisation (i18n)
When you enable internationalisation, documents are allocated additional versions, two (draft and published) for every locale that is registered. For example, a single Post document have have the following locales:
- English (
en) - Hindi (
hi) - French (
fr)
Each locale-specific version is treated as a variation of the same document, but with its own independent draft/publish versions.
This means you could have:
- An English version published and up-to-date
- A Hindi translation still in draft, being reviewed
- A French version published but awaiting updates
Strapi links these translations together under the same parent document, because they all represent the same logical piece of content across languages.
Recap
A document in Strapi is more than just a row of data:
- It represents an instance of a content type (e.g. one post).
- It can have multiple locale variations, with each localized variation having its own draft/published versions.
- Each variation of a document has two versions — a published version and a draft version.
- Each locale variation of a document can exist in either a draft or a published state, independently of the other variations of the document.
In other words:
A document is basically is container/bucket for a piece of content, and all its variations.
On this project
We have the following content-types:
- Pages
- Posts
- Post Categories
- Color Schemes
- Page Contexts
An instance of the Pages content-type is basically a "page document". The "Privacy Policy" page is a page document of the content-type "Pages".
No internationalization has been enabled, hence each document has just one default locale variation.