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. 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 |
|
|||
Mixin node type |
|
|||
Magnolia node type |
|
The
|
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.
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 |
---|---|
|
The base type of all primary node types. |
|
Unstructured node type that allows any properties and child nodes. |
|
Abstract base type for nodes in a structured node hierarchy. |
|
JCR representation of a file. |
|
This node type is used in the versioning system. |
Magnolia primary node types
The primary Magnolia node types are defined in:
magnolia-nodetypes.cnd
These types are required for the basic features of Magnolia to function: configuration, page-editing and rendering as well as publishing from author to public (which relies on versioning).
Notation | Description |
---|---|
|
Area |
|
Component |
|
Publishable and versionable content objects such as pages. |
|
Publishable but not versionable content objects which can be rendered independently. For example, blocks or objects below page level such as area or component. |
|
Folder |
|
Group |
|
Metadata |
|
Property |
|
Page |
|
Reserved for system use. |
|
Resource |
|
Role |
|
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 |
---|---|
|
Mixin type for referenceable nodes. Provides an
auto-created |
|
Mixin type for versionable nodes. |
|
Enables locking capabilities for a node. |
Magnolia mixin node types
Notation | Properties | Description | ||
---|---|---|---|---|
|
|
Date the node was deleted, the user who deleted it and the deletion comment. |
||
|
|
Date the node was last modified and the user who modified it. |
||
|
|
Date the node was published, the user who published it, its current publication status and the version in which the node was published.
|
||
|
|
Date the node was created and the user who created it. |
||
|
|
Associates a template with the node for rendering. |
||
|
|
Allows the user to leave a comment on the version. |
||
|
|
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) {
query = "/jcr:root" + path + "//* order by @name"; //i.e. path=/travel/about
try {
NodeIterator nodes = QueryUtil.search(workspace,query,Query.XPATH,returnItemType);
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");
Options from the expandable Groovy script above:
-
workspace
: Any Magnolia workspace. -
path
: A valid path in the workspace./
will search for everything under the workspace root. -
returnItemType
: A valid JCR node type. The query goes through all node types but the results are filtered to the node type you specify. Usent:base
as awildcard
.
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.xml
.
Notation | Description |
---|---|
|
An object containing a
category.
Inherits from |
Content Editor module
Defined in
content-editor-nodetypes.cnd
.
Notation | Description |
---|---|
|
Content editor block objects containing text, image or
similar content. Inherits from |
|
Compositions are publishable and versionable as a
whole and contain ordered subnodes of type |
|
Collection of unordered content editor compositions. |
Content Tags module
Defined in
content-tags-nodetypes.xml
.
Notation | Description |
---|---|
|
An object containing a content tag. Inherits from
|
Marketing Tags module
Defined in
magnolia-tags-nodetypes.xml
.
Notation | Description |
---|---|
|
An object containing a
marketing
tag. Inherits from |
Password manager module
Defined in
magnolia-keystore-nodetypes.xml
.
Notation | Description |
---|---|
|
An object containing a password. Inherits from
|
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) also in light modules.
Please read the page Defining JCR node types and workspaces, which provides an overview of all ways to define custom JCR node types and create new workspaces with Magnolia.