Note: the models and components you get with each of our themes differ in various ways, but also share a lot of similarities. This guide showcases some of these common patterns, with code snippets that are edited for simplicity.

Pages, Sections & More

Our themes all come with two main models for building pages: the general-purpose PageLayout, and the content-focused PostLayout for blog posts and similar items.

The secret sauce in these models, if there is one, is making the model flexible enough so you could use the same one for a wide range of needs. Let's follow with a very brief taste of this flexibility.

PageLayout

Here's most of the actual definition for this model that you'll find in any of our themes:

name: PageLayout
label: Page
fields:
  - type: string
    name: title
    label: Title
    default: This is a new page
  - type: list
    name: sections
    label: Sections
    items:
      type: model
      groups:
        - sectionComponent

Aside from the title field, there's only one other field: sections. It is defined as a list of other content objects, but not of any type but only content whole type (i.e. model) belongs to the sectionComponent group.

Here is an excerpt from a common model in this group - the HeroSection model:

name: HeroSection
extends:
  - Section
groups:
  - sectionComponent
fields:
  - type: string
    name: title
  - type: string
    name: subtitle
  - type: markdown
    name: text
  - type: list
    name: actions
    label: Actions
    items:
      type: model
      models:
        - Button
        - Link

There are multiple other models in the sectionComponent group. Many of them extend the base Section model, inherting its fields and extending it with their own, but that's definitely not a necessity: model groups are merely logical groupings (learn more).

You can also see in the example above how the model definition includes buttons and links, which are also reusable models.

PostLayout

Unlike PageLayout, the PostLayout model has a Markdown-formatted content, plus and a field for linking an author object. Like the general-purpose PageLayout, it also supports adding sections to pages - so you can spice up specific blog posts with additional calls to action or other information without needing to break or escape the post template.

Hopefully, even without knowing the specifics of models yet, you can already get a sense of the flexibility this schema affords.

To learn more on what a section is, and for the rest of the questions you probably have, proceed from this guide to the next one: Components.

Site-Wide Configuration & Styling

Site-wide configuration is also defined via models. Here's the basic definition for the Config model. It's pretty simple to start with:

name: Config
label: Site configuration
fields:
  - type: model
    name: header
    label: Header configuration
    models: [Header]
  - type: model
    name: footer
    label: Footer configuration
    models: [Footer]

This is a somewhat different kind of model: it does not represent a page, and there should be only one instance of it - which should be provided to all relevant rcomponents that need it. These details are all handled by our base themes which pre-configure this for you when creating a new project. Then, this model and the ways it's used are yours to extend or customize.

The same approach is used to define global styling options for the project - default colors, fonts and more. Learn more about these objects in How Stackbit Works and the How-to Guide on global styles.

Next up: Providing a better visual experience to content creators.