This page describes how to use YAML in Magnolia. You can use YAML to define items such as templates, dialogs and apps, and you can import and export content in YAML.
YAML is generally easier to work with than XML. It is easier for humans to read and edit since the content structure is readily visible in YAML. For example, importing multi-line quotes or special characters needs no escaping. YAML is also easier for developers to diff and merge, and the format is more convenient when creating import files from other data sources.
Magnolia uses the SnakeYAML processor to parse YAML. The data is transformed by
YAML as definition files
YAML files are primarily meant to define (configure) items such as apps, templates, dialogs.
Example: A YAML definition of a
What can be defined via YAML?
- App definitions
- Content type definitions
- Dialog definitions
- Field type definitions
- Media editor definitions
- Message view definitions
- Renderer definitions
- REST endpoint definitions
- Template definitions
- Theme definitions
- Virtual URI mappings
- Workflow definitions
- Work item handler definitions
Items defined in the
configuration workspace can be downloaded as YAML to move the configuration into a file.
In a running system, the data written in YAML is represented by a Java Bean. The following table lists Magnolia YAML files and their corresponding Magnolia classes, usually called definition or description classes.
|Item||YAML file||Corresponding definition class*|
* You can also use custom definition classes which will usually extend the classes mentioned above. In this case you have to provide the class as an attribute in the YAML file.
Deprecating a YAML-based definition with
The introduction of the
info.magnolia.config.source.yaml.construct.WrapMetadata construct in Magnolia 5.6.2 allows you to deprecate YAML-based definitions. You can mark a YAML-based definition as deprecated like this:
The deprecated definition is displayed in the Definitions app. Currently, the app reports the following deprecated (or non-existing) items:
- Deprecated classes used by any definition.
- Deprecated or non-existing templates used by block definitions.
- Deprecated or non-existing page template definitions referenced from site definitions.
- Deprecated or non-existing theme definitions referenced from site definitions.
- Template references.
- Deprecated or non-existing dialogs
- Deprecated or non-existing component definitions used in page definitions.
- Non-existing template script paths.
- Configured but non-existing renderer.
Reusing configuration in YAML files with
Magnolia provides two mechanisms to reuse a configuration within a YAML-file:
!include . You can use them not only to reuse a definition but also to modify a reused definition.
Use the Magnolia
!inherit directive to inherit a registered definition item in order to create a new definition item, and then modify the new item according to your needs. This directive is very similar to JCR extends. The item you inherit the definition from is referenced by its identifier.
The new renderer named
json inherits everything from the
freemarker renderer but has a different contentType.
Reference a field by its name
Instead of defining the type of a field using the
class property, you can reference the type using the
fieldType property, which takes the field's short and easy-to-remember alias name as the value.
For example, use
fieldType: text instead of
For more information read the YAML inherit and include page.
Use the Magnolia
!include directive to add a reusable YAML chunk. Include a fragment on a sub-level of your new definition or include a complete definition on top of your new definition. Reference the file you include by its resource path. The path to such a resource has the following pattern:
You can also modify the included part of the definition.
Syntactic variants of the directive
!include directive exists since Magnolia 5.4, which introduced configuration by YAML. However, the directive's syntax has changed slightly with the release of Magnolia 5.5.6. While the old syntax still works, the new one makes it possible to modify and override the included part of the definition. The new syntax uses a colon
: instead of the space
!include and the path to the resource.
|Deprecated syntax. ( Magnolia 5.5.6+)|| ||Magnolia 5.4+||simple include|
|New syntax.|| ||Magnolia 5.5.6+||simple include, include and modify|
- Line 6: Modify the label of the included tab.
- Lines 9 and 10: Modify the label of the
blackOrWhitefield from the include.
- Lines 14 to 16: Add another action to the imported actions.
For more information read YAML inherit and include.
!override to completely ignore the properties of an inherited or included node. As a consequence, you have to add specify properties to the given node.
Reusing an existing definition within the same file
YAML's anchor property and alias indicator make it possible to reuse an already existing definition by referencing it. In the following definition snippet see, for example, the anchor
&footerAvailableComponents (line 5) and the alias
*footerAvailableComponents (line 14), which allow reusing the components defined in the
footer area also in the
With some restrictions related to overriding properties and changing subitems, YAML is currently the only way to decorate already existing definitions. For more details see Definition decoration page.
Defining a list property via YAML map or list syntax
In a YAML file, when a property type is defined as a list in the corresponding Java class, you can use the map syntax or the list syntax. Map2BeanTransformer converts YAML in both cases correctly.
Java definition classIn the given example, the type of items that go onto the list extend NamedDefinition, which is very typical for any (sub-)item definition class. This means that items going onto the list must define a
List syntaxWith the list syntax, you typically start with the
Map syntaxWith the map syntax, the map keys (lines 3 and 6) are used as the
nameproperty by Map2BeanTransformer. You can override it by setting the
nameproperty explicitly (line 7).
YAML for importing and exporting JCR content
YAML can also be used to export and import JCR content, which was originally possible only with XML files.
Example: An export of a simple page node in YAML format
- Whitespace indentation is used to denote structure; however tab characters are never allowed as indentation.
- Comments begin with the number sign (
#), can start anywhere on a line and continue until the end of the line. Comments must be separated from other tokens by white space characters.
- Strings (scalars) are ordinarily unquoted, but may be enclosed in double-quotes (
"), or single-quotes (
Members of a sequence are lines beginning at the same indentation level, and starting with a leading hyphen and at least one space (
- ). The number of spaces after the leading hyphen must be the same for all members in the sequence.
Mappings (also known as dictionaries in YAML, or just maps informally) are represented in a simple
form (the colon must be followed by a space):
Using empty values in sequences and mappings
If you need to set an empty value in a map or sequence, use the empty brackets notation as shown in the following examples:
A null value used in the way as on line 5 below is reported as a warning with severity level
minor in the Definitions app.
Combinations of mappings and sequences
Let's combine some mappings and sequences, which is a common use case in Magnolia YAML files.
- The root structure of this file is a mapping.
- The values of the
drinksmappings are sequences.
- The value of the mapping with the key
languagesis also a mapping.
Further resources about YAML
YAML specification and documentation
- yaml.org (The Official YAML Web Site)
- snakeyaml (the YAML parser used by Magnolia)
Editors supporting YAML syntax
- Atom (YAML related packages)
- Eclipse (with plugin)
- Emacs (with plugin)
- IntelliJ (with plugin)
- Light Table
- Sublime text
- Vim (with plugin by YAML's original author)
Online YAML tools
- Parsers and linters