Developing and rendering custom content blocks

This page describes how to define and render custom content blocks that can be grouped to form content compositions in implementations of the Content editor.

Compatibility note

Magnolia 6 UI framework is implemented in version 2 of the Content Editor module. Custom content editor and block definitions created in the Magnolia 5 UI framework are not compatible with this version of the module and must be migrated.

If you wish to keep using the existing 5 UI block and custom content editor definitions, you must install version 1.3.10 of the Content Editor module and use them with this version.

Block types

The Content editor provides predefined block types that you can use in your custom content editor app:

  • text - Compared to TextFieldDefinition, the text block implements a special LightRichTextFieldDefinition class, which features basic text formatting functions:

    Light RichText Field block with control box

    templateId: content-editor:blocks/text
    icon: text-block
    label: Text
    block:
      implementationClass: info.magnolia.editor.field.LightRichTextFormView
      properties:
        text:
          class: info.magnolia.editor.field.LightRichTextFieldDefinition
          linkableApps:
            - pages-app
            - dam-chooser
  • image - Configured using the ordinary 6 UI damLinkField and textField field types:

    templateId: content-editor:blocks/image
    icon: file-image
    label: Image
    block:
      properties:
        image:
          $type: damLinkField
          label: Image
          placeholder: Add image...
          buttonSelectNewLabel: Select new...
        imageAltText:
          label: Alt text
          $type: textField
          placeholder: Add alt text...
        imageCaption:
          label: Caption
          placeholder: Add caption...
          $type: textField
        imageCredit:
          label: Credits
          placeholder: Add credits...
          $type: textField
  • externalLink - Utilizing the PeekFieldDefinition class from the Magnolia Link Unfurl Module, a submodule in the Content Editor module.

    templateId: link-unfurl:components/externalLink
    icon: embed
    label: Embed content
    block:
      properties:
        url:
          class: info.magnolia.unfurl.ui.PeekFieldDefinition
          label: Embedded content
          validators:
            url:
              class: info.magnolia.unfurl.ui.UrlValidatorDefinition
              errorMessage: link-unfurl.components.externalLink.tabUrl.url.validation.errorMessage
  • video - A combination of the following 6 UI field types: checkBoxField, comboBoxField, damLinkField, expandingTextField, radioButtonGroupField, switchableField and textField.

Demo block types

The Magnolia Demo decorates the default Stories app and provides two additional block types you can use:

  • date

  • tour

These block types implement the 6 UI dateField and linkField, respectively. To see these blocks, you must have the Magnolia demo modules installed.

Defining a custom block

You can quickly create your own custom block using Magnolia CLI. The Magnolia CLI create-block command. The command creates a block based on the info.magnolia.block.BlockDefinition class and includes many commonly used fields as a starting point: text, page link, DAM image, multivalue and select.

To define a custom block, use a YAML definition file and apply the BlockDefinition class of the Content editor module.

  1. Create a YAML file in the blocks folder of your module and add the following required definition elements:

    1. The info.magnolia.block.BlockDefinition class.

    2. The templateId of your block.

    3. A block node, with a list of fields the content block consists of. Use the properties in the same way as the properties for the CompositeFieldDefinition.

      class: info.magnolia.block.BlockDefinition
      templateId: <module-name>:<the-path-to-the-block-relative-to-the-module>
      icon: <icon-name>
      label: <i18n-label>
      block:
        itemProvider:
          $type: jcrBlockGetIndexedChildNode
        properties:
          field1:
            <field1-property1>
            <field1-property2>
          field2:
            <field2-property1>
            <field2-property2>
            etc.
  2. Provide a template definition file and a template script for your block in the templates/blocks subfolder of your module.

  3. Optionally, in the i18n folder of your module, provide a file with i18n keys for labels and descriptions of the block’s fields.

Rendering blocks in a FreeMarker script

This section explains how to render block content in a page or a component template.

The cms:block directive

The Content editor module provides cms:block, a Magnolia FreeMarker directive for fetching and rendering block elements.

The directive expects a node of the type mgnl:block as argument, identifies the template definition of the block and calls the associated template script.

[#assign blocks = cmsfn.children(articleContent, "mgnl:block") /]
  [#list blocks as block]
    [@cms.block content=block /]
  [/#list]

Examples of block rendering

The examples show how to render blocks within a template script of a page or component template. Using the Magnolia directive cms.block, the template script of the block is executed during the rendering of the page or component.

  1. Get story content:

    [#assign articleContent = cmsfn.contentById(content.article, "") /]

  2. Get the blocks for that story:
    [#assign blocks = cmsfn.children(articleContent, "mgnl:block") /]

  3. Retrieve all blocks for a piece of content:

    [#if articleContent?hasContent]
      [#assign blocks = cmsfn.children(articleContent, "mgnl:block") /]
      [#list blocks as block]
        [@cms.block content=block /]
      [/#list]
    [/#if]

    Line 4: The Magnolia directive cms.block ensures that the template script associated to the passed block is called to render the block content.

  4. Retrieve two blocks, for instance to display an excerpt of a story in a list:

    [#if articleContent?hasContent]
      [#assign blocks = cmsfn.children(articleContent, "mgnl:block") /]
      [#list blocks as block]
        [#if block?index == 2]
          [#break]
        [/#if]
        [@cms.block content=block /]
      [/#list]
    [/#if]

    Line 7: The Magnolia directive cms.block calls the template script associated to the passed block content.

Content internationalization (i18n)

Internationalization (i18n) of content is not supported in the 1.3.x and 2.0.x versions of the Content Editor module and its Stories app submodule.

The feature will only be enabled in version 2.1. Until it is released for production-ready use, you cen test it out in version 2.1-beta. This version is available on Magnolia Nexus under the following coordinates:

<dependency>
  <groupId>info.magnolia.editor</groupId>
  <artifactId>content-editor-parent</artifactId>
  <version>2.1-beta</version>
</dependency>

Before adding this beta into your webapp, you must remove the bundled version of the module.

Compatibility of content and block definitions

Flat vs nested content structure

The data model for the internationalized Content Editor stories is different in the beta version. Whereas in 1.3.x and 2.0.x the mgnl:block elements are stored in a flat node structure,

stories
└── story1
    ├── 0
    └── 1

in the i18n-supported version, the nodes are locale-nested under intermediate nodes of type mgnl:contentNode, named custom_de and custom in this example:

stories
└── story1
    └── custom_de
    │   ├── 0_de
    │   └── 1_de
    └── custom
        ├── 0
        └── 1

This must be reflected in your MultiJcrBlockDefinition, where you need to add and enable the i18n property.

Instead of the CurrentItemProvider, the CompatibleBlockProvider is set as the default provider, which can resolve both flat and nested block nodes. You do not need to declare it in your block definition.

Example definition
custom:
  label: Blocks
  $type: multiJcrBlock
  i18n: true
  blocks:
    - text
This applies only to the 2.0.x block definitions. Block definitions created for version 1.3.x (5 UI) of the module are not compatible with the 2.1-beta version and must be fully migrated.

Migrating content to 2.1-beta

There are two ways you can migrate the non-i18n blocks to the i18n-compatible hierarchy: using a version handler or a Groovy script.

Version handler

When upgrading the Stories app submodule to version 2.1-beta (or 2.1 once available), all block nodes in the stories workspace will be moved to intermediate nodes, see the MigrateBlockToIntermediateParentTask task.

Groovy script

You can run the migration task in the Groovy app, especially in case a block node is stored in another workspace.

Example Groovy script
import info.magnolia.editor.setup.MigrateBlockToIntermediateParentTask
import info.magnolia.module.InstallContextImpl
import info.magnolia.module.ModuleRegistryImpl
import info.magnolia.objectfactory.Components
import javax.jcr.Session


Session session =  MgnlContext.getJCRSession("stories");
task = new MigrateBlockToIntermediateParentTask("stories", "/", "custom");
task.execute(Components.newInstance(InstallContextImpl.class));
session.save();

The parameters in the MigrateBlockToIntermediateParentTask:

Editing and publishing aspects
Locale selector is disabled

The locale selector combo box is disabled in the following cases:

  • The multiJcrBlock field is configured with i18n: true but the story structure has not been migrated yet.

  • The story complies with the new i18n structure but the multiJcrBlock field is configured with i18n: false.

Publishing stories with multilanguage content

When you publish a story where multilanguage content is enabled and present, the whole story node is published, that is all language variants of the blocks in the story are always published.

Feedback