Start a project

Models & blocks

Tell Moteur once what each client publishes.

Say once what an article, an event or a product holds, and which blocks a page may use. Your developers build against it, the client’s team fills it in, and the API refuses whatever doesn’t fit.

Start a projectMoteur for agencies
The Article model in the Studio’s Setup: seventeen fields listed with their kind, languages and whether they’re required. The Body field is open beside the list: “Blocks, a page built from blocks”, required.The Article model in the Studio’s Setup: seventeen fields listed with their kind, languages and whether they’re required. The Body field is open beside the list: “Blocks, a page built from blocks”, required.
The Article model: seventeen fields, and a body made of blocks.

Try to break it

The rule holds, whoever saves

Théo allowed five kinds of block in this body, one to six of them. Add what you like, forbidden ones too, then save. An editor, a script or an agent would get the same answer.

The rule, in the model

{
  "type": "core/block-list",
  "label": "Body",
  "options": {
    "allowedBlockTypes": [
      "core/paragraph",
      "core/heading",
      "core/image",
      "core/quote",
      "demo/pull-quote"
    ],
    "minBlocks": 1,
    "maxBlocks": 6
  }
}

Body

  1. Headingcore/heading
  2. Paragraphcore/paragraph
  3. Imagecore/image
  4. Paragraphcore/paragraph

Add a block

The API answers

Save, and the answer shows here.

Théo’s rule is an example. The answers are word for word what Moteur sends back.

Set up once

What a model holds

Your developers set it up once per client. After that, nobody on the client’s side can bend it out of shape.

  • Fields

    Forty kinds of field

    Text, rich text, dates, media, links to other entries, lists, tables, colours, addresses, 3D models, and lists of blocks.

    • Required, or not
    • In every language, or once

  • Blocks

    Only the blocks you allow

    A page body takes only the blocks you list, as many as you allow. The client builds freely inside those lines.

    • Nothing your frontend can’t draw
    • The same rule for pages

  • Structures

    Groups you reuse

    Fields you need in many places, like a page’s search title, description and share image, defined once.

    • Change it once, it changes everywhere
    • Search fields included

  • Git

    Files in Git

    Each model is a file in the project’s Git repository. Every change to it is a commit with a name on it.

    • Review a model change in a pull request
    • Restore an old one in the Studio

  • Roles

    Changed by builders and developers

    Writers fill models in. Changing one takes a builder or a developer, and the API refuses anyone else.

    • Your client’s team can’t undo your setup
    • Set per project

  • Studio

    The form follows

    The Studio builds each editing form from the model’s fields. You never code an editing screen.

    • The form keeps up with the model
    • Sections, if you want them

On disk

A model is a file you can read

The demo journal’s Article model, as a file in its repository. Review it in a pull request like the rest of your code.

  • Six of its seventeen fields
  • With no list of blocks, Body takes any block

models/article/model.json

{
  "id": "article",
  "label": "Article",
  "modelType": "content",
  "fields": {
    "title": {
      "type": "core/text",
      "label": "Title",
      "options": {
        "multilingual": true,
        "required": true,
        "maxLength": 140
      }
    },
    "slug": {
      "type": "core/slug",
      "label": "Slug",
      "options": {
        "sourceField": "title",
        "multilingual": true,
        "required": true
      }
    },
    "author": {
      "type": "core/relation",
      "label": "Author",
      "options": {
        "model": "author",
        "required": true
      }
    },
    "cover": {
      "type": "core/asset",
      "label": "Cover image"
    },
    "body": {
      "type": "core/block-list",
      "label": "Body",
      "options": {
        "required": true
      }
    },
    "seo": {
      "type": "core/structure",
      "label": "SEO",
      "options": {
        "structure": "core/seo"
      }
    }
  }
}

Questions about models

A developer asksWhat happens to existing entries when I add a field?

MoteurNothing changes in them. The new field stays empty until someone fills it in. If it’s required, it’s asked for before the entry goes to review or live.

A developer asksAnd when I remove one?

MoteurIts values stay in the entries’ files, unread. Put the field back and they’re there again, or restore the model from its history.

An agency owner asksCan a client’s team change the models?

MoteurOnly if you make them builders. Writers, reviewers and translators fill in entries. Changing a model takes a builder or a developer, and the API checks.

A reader asksCan we add our own kinds of field?

MoteurYes. With the plugin SDK, add a field or a block of your own, beside the forty.

A developer asksDo we get TypeScript types for our models?

MoteurYes. `moteur types` writes them from a channel: every model, block and structure, all the way down. Commit the file, and with --check, CI fails when it falls behind the project.

A developer asksCan one field hold different kinds of things?

MoteurYes. A variant field holds one of several shapes, each with its own fields: an exhibit that is a picture, a code listing or a video. The writer picks one, saving checks that shape, and the site gets only its fields.

An agency developer asksCan a link point to one of our pages?

MoteurYes. A link or a relation can point to a page instead of an address. The site gets the page’s address in each language, it follows the page when it moves, and a page that isn’t live comes without one, so nothing links to a dead end.

Keep reading

Model your next client’s site.

Start a free project, write one model, and see the Studio’s form appear.

Start a projectMoteur for agencies