Written by The Jahia Team
   Estimated reading time:
7.1 7.2 7.0 7.3

Jahia is based on JSR 283. each content item (you can compare that to a "record" in the RDBMS world) is stored as a node in the repository, each node has a a unique identifier (UUID) and a unique path from the repository root level. Also a node can have multiple properties (you can compare properties to fields in the RDBMS world) which are usually driven by a definition. Nodes are organized in a tree, which is major difference with RDBMS where content is organised in flat tables. A node can have 0 to n child. Each node is accessible through its path, absolute from the repository root node, or relative from the current node. In the following pages are explained the basic informations about content modeling,

We strongly recommand developpers to read and rely on the JCR 2.0 specification and notably the repository model


A node follow a definition (NodeType) declared in a text based file using the .cnd extension

By convention definition files are usually named definitions.cnd but it is not an obligation

The definition is identified by a domain and a name [domain:name]


The nodeType can inherit from other definitions

[cnt:mainContent] > jnt:content

and can be extended by applying mixins

[cnt:mainContent] > jnt:content, mix:title, jmix:structuredContent

then, the definition specifies its own properties. 


Properties can be compared to fields in a DB. Properties are defined for each nodeType in the definition declaration.

Each property has a name

- name

- myfield

and a type

- name (type)

- myfield (string)

the definition can also specify an input mask

[cnt:mainContent] > jnt:content, mix:title, jmix:structuredContent
- myfield (string,richtext)

Properties types

  • string
  • binary
  • weakreference
  • date
  • double
  • long
  • decimal
  • boolean

Other parameters

Multiple properties (available for string, long, double and references)

[cnt:mainContent] > jnt:content, mix:title, jmix:structuredContent
- myfield (double) multiple

Internationalization infos, default values, constraints, indexation directives...

[cnt:mainContent] > jnt:content, mix:title, jmix:structuredContent
- myfield (string) i18n

Built in definitions

Jahia is bundled with a set of built-in definitions. The purpose of this page is to explain them.

Generic modifiers

extends : you can specify on which nodetype contents applies.

extends = jnt:contentList, jnt:folder

itemtype : define on which panel in the edit engine, the mixin will be display

itemtype = template


You can add mixins to any nodetype definition in order to change the way they are display in engines (User Interfaces).

edit mode (Side panel)

  • jmix:droppableContent allows content to be drop in a placeholder
  • jmix:listContent appears in content lists list
  • jmix:editorialContent appears in editorial contents list
  • jmix:siteComponent appears in site component list
  • jmix:queryContent appears in the Query component list
  • jmix:formContent appears in the form component list

other mixins

  • jmix:list define all lists in jahia, can be order. It uses all list display mechanisms
  • mix:title unify all title of contents. Also provide a description. You can access them with jcr:title and jcr:description properties.
  • jmix:hiddenNode the node will not appear in managers
  • mix:shareable This default type from the JCR specification that allows to define "shareable nodes" is not supported by Jahia and must not be used.

System, content and files

Jahia store items using this definitions.

System directories can store folders and contentLists folders can store files or folders contentlists can store contents or contentlits

System directories

They are used to store all jahia internal items

[jnt:templatesSets] > nt:base, jmix:systemNode, jmix:nodenameInfo, jmix:basemetadata, jmix:list
[jnt:usersFolder] > nt:base, jmix:systemNode, jmix:nodenameInfo, jmix:basemetadata, jmix:publication, jmix:list


store all droppable contents.

[jnt:contentList] > jnt:content, jmix:listContent, mix:title, jmix:list


+ * (jmix:droppableContent) = jmix:droppableContent version


store all files and folders.

[jnt:folder] > nt:folder, jmix:nodenameInfo, jmix:basemetadata, jmix:publication, jmix:observable


A node can be reused in different places by using reference nodes. Reference nodes are simple nodes containing a reference property to another node.

Reference nodes

There are multiple reference node types depending on the type of node that have to be referenced. All node types inherits from jmix:nodeReference . The rendering can be different depending on the reference node type :

  • Content reference (jnt:contentReference) : References any other content that can be used in a page.
  • File reference (jnt:fileReference) : A simple link to a file
  • Image reference (jnt:imageReference) : Includes an image into a page
  • Content folder reference (jnt:contentFolderReference) : Displays all content in a content folder

All these nodes must have a j:node property which contains the referenced node. Some reference node types may define a j:node as internationalized, if the referenced node needs to be different for each language. This can be useful for documents or images which contain text. The types jnt:imageI18nReferencejnt:fileI18nReference, for example, are internationalized.

Creating a reference

References can be created in the edit mode by using copy/paste as reference or by dropping an existing content to an area. Jahia will propose the list of reference node types that are available for the content being dropped and that can be created in that area.

Referenced node path

In case of multiple sites, they must have different server names and be accessed with these server names when referencing nodes between them

It is possible to dereference a reference node in a path by using the separator @/. If the node : /sites/ACME/home/maincontent/article-ref is a content reference to the node : sites/ACME/home/publications/maincontent/article , it is possible to use the path : /sites/ACME/home/maincontent/article-ref@/article. All subnodes can also be accessed with this path, like : /sites/ACME/home/maincontent/article-ref@/article/paragraph1

When getting a node through reference.getProperty("j:node").getNode(), the path will contain a dereference of the j:node property.

The same node can then be retrieved with different paths. It's possible to get the unique path without dereferences by using the method getCanonicalPath().

The main advantage of using a path containing the reference node is to be able to keep the context of the reference : the parent of the node article will be the article-ref. All breadcrumb or modules dislpaying the path will show the content as if it was really created here.

Also, the associated site node is the site node of the reference node, not the one of the node being referenced. All code based on the site of the node, like template resolution, will use the site of the reference node.

User generated content

User generated content is content created by visitors of a website while browsing the published version of this site (without accessing to Jahia edition modes and UIs)

Content organization

User generated content is directly created in the live workspace through input forms, whether this content has a direct impact on the page (ex: post a comment and display it in the page) or is only stored and is not displayed (ex: submit a request form). this content is stored under a page or content node previously created in the default workspace that has been published in the live workspace (remember that a comment form itself or any other form is originnaly a content node in edit mode). Then all user generated content should be organized under a standard content item.

For example, in the Forum app, the forum-home page is created by the editor in edit mode (default workspace). Once pulished, the forum homepage allows the user to create rooms under this home. The rooms and all content underneath will be created only in the live space :

|-----forum-room (live only)
|-------forum-section (live only)

However, the editor can also create a forum-room page and publish it - the sections below the room will be created in live workspace :

|-----forum-section (live only)

Security aspects

Website users must not have any permission to edit or change the live workspace - they should rather use predefined actions, which will constrain the data they can change.

These actions can be used with a tokenized form, so that they have full access to the repository. See actions for more information about tokenized form and captchas.

The form aimed at creating User Generated Content should not be available in edit or preview mode, and they can be available only for some users - this is usually configured in the studio, in the "permissions" tab :


The form will be blocked in edit :


Full read-only mode

When Jahia mode does not allow write operation in the JCR (full read-only mode, maintenance mode, etc.), the content updates should be avoided. In order to prevent the case of a user trying to create some UGC when the read-only mode is activated, you can use the following code snippet in the jsp of your module, to handle such case (by showing a message mentioning that comments are temporarily disabled while hiding the add comment form for instance):


<c:if test="${renderContext.readOnly}">


<c:if test="${renderContext.readOnlyStatus != 'OFF'}">


  • Web projects
    Web projects (previously called virtual sites) are spaces dedicated to a specific web site. They are usually be bound to a server name, contain a home page a structure of sub pages. They are represented by a jnt:virtualsite node, stored under the /sites node.
  • Modules
    A web project has its own modules. Modules are not usable until they are enabled on a webproject.
    When a module is enabled, its name is added to the webproject  j:installedModules property.
  • Files and content
    Each web project has its own space to store files and content, directly under the site node. A web project can also have its own groups and users.