Node types

Magnolia stores data in a Java Content Repository. The repository is a hierarchical object database that is particularly well-suited for storing content. In a content management system you need to be able to store text, documents, images and other binary objects along with their metadata. The data is structured as a tree of nodes. Each node can have one or more types. The type defines what kind of properties the node has, the number and type of its child nodes, and its behavior.

Want to know more?

See Jackrabbit Node Types for more information and Node Type Visualization for a diagram of the node type hierarchy.

In Magnolia we define custom node types that define Magnolia’s custom content model. The JCR in turn enforces the constraints of that model at the repository level. If you need to reference JCR node types in your code, Jackrabbit’s JcrConstants is useful. We provide constants also for Magnolia’s custom node types but also convenience methods.

For example, to update the last modification date of a node, use the NodeTypes.LastModified.update(node) convenience method. Magnolia node types are registered by the info.magnolia.jcr.util.NodeTypes class.

Prefixes

Node type Prefix Notes

JCR primary node type

nt:

Mixin node type

mix:

Magnolia node type

mgnl:

The mgnl prefix does not tell you whether the node is a primary node or a mixin.

To find out which type a mgnl node is, check the magnolia-nodetypes.cnd file.

Node type hierarchy

In this simplified node type hierarchy diagram you can see what extends what. For example, mgnl:page extends mgnl:versionable. This means that page is an object you can version. In contrast, mgnl:area and mgnl:component are not versionable - they are subnodes that must be published together with the parent page. However, all three node types (page, area, component) are renderable which means you can render a component on its own without its parent page.

See the magnolia-nodetypes.cnd file for a full view of the Magnolia node type hierarchy.
Node type hierarchy

Primary node types

Every node has a primary node type assigned to it upon creation. The primary node type defines node structure such as allowed and required child nodes and properties. Primary types reflect the business that is represented in the repository. Magnolia’s primary node types define content management nodes such as pages, areas, components and resources.

JCR primary node types

Notation Description

nt:base

The base type of all primary node types.

nt:unstructured

Unstructured node type that allows any properties and child nodes.

nt:hierarchyNode

Abstract base type for nodes in a structured node hierarchy.

nt:file

JCR representation of a file.

nt:frozenNode

This node type is used in the versioning system.

Magnolia primary node types

The primary Magnolia node types are defined in magnolia-nodetypes.cnd2.

These types are required for the basic features of Magnolia to function:

  • configuration

  • page editing

  • page rendering

  • publishing from author to public (which relies on versioning)

Notation Description

mgnl:area

Area

mgnl:component

Component

mgnl:content

Publishable and versionable content objects such as pages.

mgnl:contentNode

Publishable but not versionable content objects which can be rendered independently. For example, blocks or objects below page level such as area or component.

mgnl:folder

Folder

mgnl:group

Group

mgnl:metaData

Metadata

mgnl:nodeData

Property

mgnl:page

Page

mgnl:reserve

Reserved for system use.

mgnl:resource

Resource

mgnl:role

Role

mgnl:user

User

Mixin node types

Mixin node types specify additional properties or characteristics to the node. A node can have a primary type and several mixin types at the same time. JCR mixins add repository-level functionality such as versioning and locking. Magnolia mixins add content management capabilities such as publishing and rendering.

JCR mixin node types

Notation Description

mix:referenceable

Mixin type for referenceable nodes. Provides an auto-created jcr:uuid property that gives the node a unique identifier that can be referenced.

mix:versionable

Mixin type for versionable nodes.

mix:lockable

Enables locking capabilities for a node.

Magnolia mixin node types

Notation Properties Description

mgnl:deleted

  • mgnl:deleted (DATE)

  • mgnl:deletedBy (STRING)

Date the node was deleted, the user who deleted it and the deletion comment.

mgnl:lastModified

  • mgnl:lastModified (DATE)

  • mgnl:lastModifiedBy (STRING)

Date the node was last modified and the user who modified it.

mgnl:activatable

  • mgnl:lastActivated (DATE)

  • mgnl:lastActivatedBy (STRING)

  • mgnl:activationStatus (STRING)

  • mgnl:lastActivatedVersion (STRING)

Date the node was published, the user who published it, its current publication status and the version in which the node was published.

On the public instance, these properties are irrelevant and removed because they would always contain the date of the previous publication, not the current one.

mgnl:created

  • mgnl:created (DATE)

  • mgnl:createdBy (STRING)

Date the node was created and the user who created it.

mgnl:renderable

mgnl:template (STRING)

Associates a template with the node for rendering.

mgnl:versionable

mgnl:comment (STRING)

Allows the user to leave a comment on the version.

mgnl:visitorReference

mgnl:visitorId (STRING)

Uniquely identifies a page visitor and the associated site content for the purposes of personal data protection(GDPR).

Same name siblings are not allowed

The Magnolia node type definition, magnolia-nodetypes.cnd, does not allow same name siblings. This means that you cannot have two nodes at the same level in the node hierarchy with the same name.

Typically same name siblings is not an issue because Magnolia enforces the constraint automatically during normal usage. However, if prior to Magnolia 5.2 you imported an XML file that was created outside of Magnolia or was edited by hand, it is possible that the XML import created a same name sibling.

Use the siblings.groovy script to find same name siblings in your repository. The example below searches for identically named areas (returnItemType is mgnl:area) in the website workspace under the /travel/about page.

See Groovy module for instructions on how to execute Groovy scripts.
siblings.groovy
import info.magnolia.cms.util.QueryUtil;
import info.magnolia.cms.core.search.Query;
import info.magnolia.cms.core.Path;
import info.magnolia.jcr.util.NodeUtil;
import info.magnolia.context.MgnlContext;
import javax.jcr.Session;
import javax.jcr.Node;
import javax.jcr.NodeIterator;
import org.apache.commons.lang.StringUtils;
import java.util.LinkedList;
def siblings(workspace,path,returnItemType) { (1)
    query = "/jcr:root" + path + "//* order by @name"; (2)
    try {
        NodeIterator nodes = QueryUtil.search(workspace,query,Query.XPATH,returnItemType); (3)

        Session session = MgnlContext.getJCRSession(workspace);
        def siblings = [];
        while (nodes.hasNext()) {
            Node node = nodes.nextNode();
            nodePath = node.getPath();
            if (StringUtils.contains(nodePath,"[")) {
              println "found same name sibling of '${node.getName()}' at ${nodePath}";
              siblings.add(node);
            }
        }
        siblings.each {
            nodePath = node.getPath();
            newName = Path.getUniqueLabel(session,nodePath,node.getName());
            NodeUtil.renameNode(node,newName);
            println "${nodePath} was renamed to ${newName}";
        }
        session.save();
    } catch (Exception e) {
        println e;
    }
}
//example
siblings("website", "/travel/about", "mgnl:area");
1 workspace: Any Magnolia workspace.
2 path: A valid path in the workspace. / will search for everything under the workspace root. For example, path=/travel/about.
3 returnItemType: A valid JCR node type. The query goes through all node types but the results are filtered to the node type you specify. Use nt:base as a wildcard.

Module-specific node types

The following sections list node types that are provided by individual Magnolia modules. You can define several node types per module if you so require. Almost all the node types added inherit from mgnl:contentNode or mgnl:content.

Categorization module

Defined in magnolia-category-nodetypes.cnd.

Notation Description

mgnl:category

An object containing a category. Inherits from mgnl:content.

Content Editor module

Defined in content-editor-nodetypes.cnd.

Notation Description

mgnl:block

Content editor block objects containing text, image or similar content. Inherits from mgnl:contentNode and are publishable but not versionable.

mgnl:composition

Compositions are publishable and versionable as a whole and contain ordered subnodes of type mgnl:block.

mgnl:collection

Collection of unordered content editor compositions.

Content Tags module

Defined in content-tags-nodetypes.xml.

Notation Description

mgnl:tag

An object containing a content tag. Inherits from mgnl:content.

DAM module

Defined in magnolia-dam-nodetypes.xml.

Notation Description

mgnl:asset

An object containing an asset.

Marketing Tags module

Defined in magnolia-tags-nodetypes.xml.

Notation Description

mgnl:marketing-tag

An object containing a marketing tag. Inherits from mgnl:content.

Password manager module

Defined in magnolia-keystore-nodetypes.xml.

Notation Description

mgnl:password

An object containing a password. Inherits from mgnl:content.

Custom node types

To meet your needs you can define custom content types and with the Magnolia Content Types module, you can define them (together with workspaces) in light modules too.

Please read the page How to define JCR node types and workspaces, which provides an overview of all ways to define custom JCR node types and create new workspaces with Magnolia.
Feedback

DX Core

×

Location

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

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules