Page tree
Skip to end of metadata
Go to start of metadata

Magnolia stores content in the magnolia repository. The repository is further divided into workspaces.

List of workspaces

Workspaces in the magnolia repository:

WorkspaceWhat it containsHow to view itCreated by
articlesSample stories used in the Stories app.Stories appContent Editor module
configConfiguration for Magnolia and all modules.Config appMagnolia
contactsSample contacts used in the Contacts app.Contacts appContacts module
damDigital asset management system storage for images and video.Assets appDigital Asset Management module
forumPage comments and forum posts.Forums appForum module
googleSitemapsSitemap dataGoogle Sitemap app Google Sitemap module
imagingDynamically created images used in teasers.JCR BrowserImaging module
keystorePasswords managed by the Passwords manager module.JCR browserPassword manager module
messagesMessages such as publication requests.Pulse AdminCentral module
MgnlSystemSystem information for Magnolia internal use.  
MgnlVersionVersioning information for Magnolia internal use.  
profilesUser favorites (bookmarks)FavoritesAdminCentral module
resourcesCSS files, JavaScript filesResources appResources module
rssRSS feedsFeeds appRSS Aggregator module
scriptsGroovy scriptsGroovy appGroovy module
tasksTasksPulseTask Management module
templates(typically nothing, legacy workspace for in-place templates)JCR BrowserIn-place Templating module
toursTours of the travel demo.Tours appTours module
usersSystem, admin and public users.Security appMagnolia
userrolesUser roles and ACLs.Security appMagnolia
usergroupsUser groups.Security appMagnolia
websiteWeb pages, areas and components.Pages appMagnolia

(info) In Magnolia we sometimes refer to a workspace as a "repository" for historical reasons. But it really is a workspace.

Adding a custom workspace

To add your own workspace:

  1. Create a module descriptor.
  2. Add a repositories section, a workspaces section, and register your workspace inside it.
  3. Optional: To register custom node types, add a nodeTypeFile section and provide a relative path to the XML file that defines the node types.

Example: The Contacts app module registers a workspace named contacts in the magnolia repository. It also registers a custom node type which is defined in a separate XML file. This is an abbreviated snippet from the complete Contacts app module descriptor.

contacts.xml module descriptor
<?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 the workspace

Magnolia uses a defined workspace name also for creating a backend 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.

For more information, see also

3 Comments

  1. Just managed to create workspace called "404links" w/o any problems on h2 ... and then failed utterly on derby. Looking here, it seems that error should have happened the other way around, perhaps we should double check the rules ... and perhaps we should include most common production DBs as well (MySQL, Postgres).

    1. Got you,

      Here is the difference which probably cause the issue - we have a static prefix for H2 (pm_) while Derby doesn't:

  2. well spotted. Hmm. I wonder if we should change that for new installations.