Workspaces
Magnolia stores content in the magnolia repository. The repository is further divided into workspaces.
List of workspaces
Workspaces in the magnolia repository:
In Magnolia we sometimes refer to a workspace as a repository for historical reasons. But it really is a workspace.
| Workspace | What it contains | How to view it | Created by |
|---|---|---|---|
|
Categories assigned to content. |
Categories app |
Categorization module |
|
Configuration for Magnolia and all modules. |
Config app |
Magnolia |
|
Sample contacts used in the Contacts app. |
Contacts app |
Contacts module |
|
Digital asset management system storage for images and video. |
Assets app |
Digital Asset Management module |
|
Page comments and forum posts. |
Forums app |
Forum module |
|
Sitemap data |
Google Sitemap app |
Google Sitemap module |
|
Dynamically created images used in teasers. |
JCR Browser |
Imaging module |
|
Passwords managed by the Passwords manager module. |
JCR browser |
Password manager module |
|
Marketing tags – snippets of code inserted on Web pages. |
Marketing Tags app |
Marketing Tags module |
|
Messages such as publication request approvals. |
Tasks app |
AdminCentral module |
|
System information for Magnolia internal use. Among other things, it’s used in the rollback procedure on public instances. |
||
|
Versioning information for Magnolia internal use. This workspace keeps track of various versions; see Versioning for more details. |
||
|
Usage metrics acknowledgement ( User profile information for SSO users:
|
JCR Browser |
AdminCentral module SSO module |
|
CSS files, JavaScript files |
Resources app |
Resources module |
|
RSS feeds |
Feeds app |
RSS Aggregator module |
|
Groovy scripts |
Groovy app |
Groovy module |
|
Sample blogposts used in the Stories app. |
Stories app |
Stories app |
|
Content tags – keywords or terms assigned to an item of content. |
Tags app |
Content Tags module |
|
Tasks app |
Task Management module |
|
|
(typically nothing, legacy workspace for in-place templates) |
JCR Browser |
In-place Templating module |
|
Tours of the Travel Demo. |
Tours app |
Tours module |
|
System, admin and public users. |
Security app |
Magnolia |
|
User roles and ACLs. |
Security app |
Magnolia |
|
User groups. |
Security app |
Magnolia |
|
User search metrics for ranking. |
Search results |
User Result Ranker module |
|
Visitor information for GDPR compliance. |
Visitors app |
Magnolia |
|
Web pages, areas and components. |
Pages app |
Magnolia |
Adding a custom workspace
With Magnolia Content Types
By utilizing the Magnolia Content Types module you can define custom JCR content types and workspaces within light modules.
|
Defining content types within light modules can be accomplished on a running Magnolia system without redeploying the WAR file of your Magnolia instances and without restarting the instance or a module. This makes it a perfect approach if you have a Magnolia Cloud subscription package. |
In just one YAML file you can define a JCR workspace, a node type and namespaces.
datasource:
workspace: tourguides (1)
namespaces:
mt: https://www.magnolia-travel.com/jcr/1.0/mt
autoCreate: true (1)
model:
nodeType: mt:tourGuide
properties:
- name: birthday
type: Date
- name: gender
- name: shortBio
type: richText
- name: contact
type: contactData
# .-
subModels:
- name: contactData
properties:
- name: email
- name: phoneNumber
- name: addresses
type: address
multiple: true
- name: address
properties:
- name: street
- name: city
- name: postalCode
- name: country| 1 | If there are no workspaces registered by the given name when the definition item is loaded and the autoCreate property is set to true, the system registers the workspace.
For more details, see Defining JCR node types and workspaces. |
With a Magnolia Maven module descriptor
To add your own workspace:
-
Create a module descriptor.
-
Add a
repositoriessection, aworkspacessection, and register your workspace inside it. -
Optional: To register custom node types, add a
nodeTypeFilesection and provide a relative path to the XML file that defines the node types.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module SYSTEM "module.dtd">
<module>
<name>contacts</name>
<displayName>Contacts App</displayName>
<description>Contacts App</description>
<version>${project.version}</version>
<dependencies>
<dependency>
<name>ui-admincentral</name>
<version>5.1/*</version>
</dependency>
</dependencies>
<repositories>
<repository>
<name>magnolia</name>
<workspaces>
<workspace>contacts</workspace>
</workspaces>
<nodeTypeFile>/mgnl-nodetypes/magnolia-contacts-nodetypes.xml</nodeTypeFile>
</repository>
</repositories>
</module>Naming a workspace
Magnolia uses a defined workspace name also for creating a back-end database table, which means that you must follow table naming rules for your database.
In H2, the default JCR persistency layer in Magnolia 5.5+, the name (non-quoted):
-
Must begin with a character from the A-Z range or with an undescore character.
In case of the Derby database, which was the default JCR persistency layer before the release of Magnolia 5.5, the ordinary identifier (i.e., the non-quoted name).
-
Must begin with a letter and, contain only letters, underscore characters (
_), and digits. -
The permitted letters and digits include all Unicode letters and digits, but Derby does not attempt to ensure that the characters in identifiers are valid in the database’s locale.