Content Types

The Magnolia Content Types module is a tool to define the content model in Magnolia.

Content models are a key consideration for every web and digital experience project you work on. It creates a shared understanding across the domains of a project, from project owners and marketing leads to content creators to developers.

It describes the key types of content in your project, the properties each of those types has and the relationships between the content types.

You must supply a content type definition for an app in order to provision the content storage.

Rapid development and deployment

Reduce your time to market with Magnolia content types by reducing development time and increasing deployments to production.

Once the content apps are in place, editors can start entering content right away. They can do so in parallel with or even before the rest of the project/template development.

Single file configuration

Developers configure all required definitions for a content type in a single YAML file within a light module. The YAML file contains both the content model and the details about where to store the data (datasource) such as a workspace.

/content-type-examples/contentTypes/tourGuide.yaml
datasource: (1)
  $type: contentDatasource
  workspace: tourguides
  autoCreate: true

model: (2)
  nodeType: mt:tourGuide
  properties: (3)
    - name: birthday
      type: Date
    - name: gender
    - name: shortBio
1 datasource required Defines the data source.
2 model required Defines the model of the content type.
3 name optional The value of the name property under properties: is automatically assigned by the name of the resource which defines the content type (such as a YAML file name without the suffix). Here, you can set the property in the content definition to override the automatically assigned value.

Content type property suffixes

When you define a content type property, you should avoid using a 2-letter suffix. This is because Magnolia reads the suffix as a language such as property_en or property_de.

If you add a 2-letter suffix, the property is not delivered when using the Delivery API.
Example
datasource:
  $type: contentDatasource
  workspace: tourguides
  autoCreate: true

model:
  nodeType: mt:tourGuide
  properties:
    - name: description (1)
      type: String
...
    - name: description_ins (2)
      type: String
...
    - name: description_in (3)
      type: String
1 A correct property name with no suffix.
2 A correct property name with an acceptable suffix.
3 An incorrect property name with the 2-letter suffix.

Automatically generated apps

Creating, editing, publishing, managing and deleting content items of a content type works best with a content app. The content types module automatically generates this app for you based on the content type definition. All you have to do is to provide a minimalistic app definition file referencing the content type definition.

/content-type-examples/apps/tourGuides-app.yaml
!content-type:tourGuide
name: tourGuides-app

Quick deployment

Use light modules to deploy new content types and apps to your production environment by pushing changes from your synced git repository to your Magnolia SaaS instance.

Model definition

A model definition, a subitem of the Magnolia Content type definition, defines the model of a content type. The model describes the properties of a content item such as name, description, asset, birthday, and so on.

Model definition properties

When designing a model don’t think about it in terms of UI elements like fields. Think in terms of what type of data the field stores. For example, a link field. stores a String type (i.e., property). The property in the model definition can be decorated in the app definition with whatever UI element stores that data type.

/content-type-examples/contentTypes/tourGuide.yaml
datasource:
  $type: contentDatasource
  workspace: tourguides
  autoCreate: true

model:
  nodeType: mt:tourGuide
  properties:
    - name: birthday
      type: Date (1)
    - name: gender
    - name: shortBio
    - name: contact
      type: contactData
  subModels:
    - name: contactData
      properties:
        - name: email
        - name: phoneNumber
        - name: addresses
          type: address
          multiple: true
    - name: address
      properties:
        - name: street
        - name: city
        - name: postalCode
        - name: country
1 Here, the type set is Date. See Magnolia SaaS content type properties for a complete list of types.

Property definition properties

This section describes the PropertyDefinition item. Property definition items can be defined in the properties property, which is a property of the model definition of a content type definition.

Table 1. <property>
Property Description

name

required

The name of the property. The name is used for storing values in the underlying data source.

type

optional, default is String

Possible values:

  • String

  • Boolean

  • Decimal

  • Double

  • Long

  • Date

  • richText

  • asset

  • The name of a submodel.

    You can only reference submodels defined in the same content type.
  • The name of a content type making a reference to another content item. Prefix the value with reference: (for example, + type: reference:tourGuide)

required

optional, default is false

Makes the property mandatory.

multiple

optional, default is false

The true setting allows storing multiple values of the property.

options

optional

Defines a parent node for a list of selectable options OptionDefinition rendered as a Select field.

model:
  nodeType: lib:book
  properties:
    - name: category
      options:
        fiction:
          value: catFiction
          label: Fiction
        poetry:
          value: catPoetry
          label: Poetry

Options dropdown

Further customization such as using an alternative control, for example a radio button group, is possible by overriding the class or the fieldType property in the app descriptor.

     value

required

Value saved to the repository when selected.

     label

optional

Option label displayed to the user.

Submodels

Use submodels to define complex content types.

Submodels are useful whenever you need a group of fields more than once. A content type model definition can contain a list of submodel definitions within the subModels property. Submodels can be used only within the content type where they have been defined.

A submodel definition has the same properties as a model, but a submodel cannot have additional submodels.

The default nodeType for a submodels is mgnl:contentNode.

Referencing content types

Projects often have multiple content types, and those types can reference each other. For example you could have a Book type and a Publisher type. The Book could have a reference to the Publisher type. Then in Magnolia authors can manage publishers in one app, and books in another app. The form for the Book app will include a control to select a Publisher for that app. This common use-case is easy to configure in the content type.

bookType example
type: reference:bookType (1)
1 Prepending reference: allows you to reference another content item.

Magnolia SaaS content type properties

The property types available for saas are:

Type Renders in UI field as:

String

textField

Double

textField

Boolean

comboBoxField

Date

timestampField

richText

richTextField

multiple

multipleField

option

comboBoxField

subModel

compositeField

reference

linkField

Try adding a content type based app yourself

See the My first content app tutorial. It will walk you through the structure of the Bookshelf app, a small content type based app, and will show you how to push it to the git repository connected to your Magnolia SaaS instance.

Bookshelf app rendered
Feedback

SaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Magnolia SaaS docs.

Main doc sections

DX Core Headless SaaS PaaS Legacy Cloud Incubator modules