Magnolia 5.4 reached end of life on November 15, 2018. This branch is no longer supported, see End-of-life policy.
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 NodeTypes Java class.
Node type | Prefix | Notes |
---|---|---|
JCR primary node type |
| |
Mixin node type |
| |
Magnolia node type |
| 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-types.xml file. |
In this 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 activated 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.
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.
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. |
Notation | Description |
---|---|
| Folder |
| Resource |
| Metadata |
| Activatable and versionable content objects such as pages. |
| Typically a content object below page level, such as area or component, that can be rendered also independently. |
| Page |
| Area |
| Component |
| Property |
| User |
| Group |
mgnl:role | Role |
| Reserved for system use. |
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 activating and rendering.
Notation | Description |
---|---|
mix:referenceable | Mixin type for referenceable nodes. Provides an auto-created jcr:uuid property that gives the node a unique, referenceable identifier. |
mix:versionable | Mixin type for versionable nodes. |
mix:lockable | Enables locking capabilities for a node. |
Notation | Properties | Description |
---|---|---|
|
| Date the node was deleted, the user who deleted it and the deletion comment. |
mgnl:lastModified |
| Date the node was last modified and the user who modified it. |
mgnl:activatable |
| Date the node was activated, the user who activated it and its current activation status. |
mgnl:created |
| 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. |
Magnolia 5.2+ The Magnolia node type definition
magnolia-types.xml
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.
Options:
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. Use nt:base
as a "wildcard". 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
.
Defined in magnolia-category-nodetypes.xml
.
Notation | Description |
---|---|
mgnl:category | An object containing a category. Inherits from mgnl:content . |
Defined in magnolia-tags-nodetypes.xml
.
Notation | Description |
---|---|
mgnl:tag | An object containing a marketing tag. Inherits from mgnl:content . |