Workspaces

Magnolia has one repository, magnolia, which in turn contains several workspaces. There is a workspace for storing website content, another for user accounts, third for configuration and so on. In JCR terms these are all workspaces. In Magnolia terms we sometimes refer to them as repositories for historical reasons. To learn more about repositories and workspaces see Content storage and structure.

List of workspaces

You can see the content of the website, config, templates, resources, data and dms workspaces in AdminCentral. Configure a custom JCR browser for the other workspaces.

Workspace structure

Each workspace contains a single-rooted tree of items. An item is either a node or a property. Each node may have child nodes and child properties. Properties cannot have children; they are the leaves of the tree. All of the actual content in the repository is stored within the values of the properties.

Here's what the object hierarchy in a repository looks like:

1. Repository contains workspaces
2. Workspace contains nodes
3. Each workspace has a single root node.
4. Node contains properties
5. Properties store values (data)

In its default configuration Magnolia Community Edition has the following workspaces:

• config. Configuration settings for everything.
• website. Websites, pages and paragraphs. This is where most of your site content is stored.
• users. System, administrative and public user accounts.
• usergroups. Groups of users.
• userroles. Roles and access control lists (ACL) for granting permissions to users.
• dms. Documents and images, typically binary data.
• mgnlSystem. For Magnolia internal use. Created by Magnolia core.
• mgnlVersion. Versioning information for Magnolia internal use. Created by Magnolia core.

Individual modules such as the Standard Templating Kit can add their own workspaces:

• templates. Page and paragraph templates in the Standard Templating Kit (STK)
• resources. JavaScript, CSS stylesheets and image files used by the STK and themes.
• data. Custom data types and data items. Created by the Data module.
• imaging. Images created by the Imaging module.
• forum. Page comments and forum posts. Created by Forum module.
• packager. Content stored by the Packager module.
• Expressions. Workflow definitions. Created by Workflow module
• Store. Running workflows. Created by Workflow module.

Mapping workspaces to repositories

Workspaces are mapped to repositories in WEB-INF/config/default/repositories.xml.

<RepositoryMapping>
    <Map name="website" repositoryName="magnolia" workspaceName="website" />
    <Map name="config" repositoryName="magnolia" workspaceName="config" />
    <Map name="users" repositoryName="magnolia" workspaceName="users" />
</RepositoryMapping>

The ability to map a workspace to a named repository provides interesting possibilities. While Magnolia keeps all workspaces in one repository by default, you don't have to. You could map a workspace to a different repository in order to:

• Provide a workspace with its own persistence manager. You could store users in one database and website content in another.
• Use a different persistence mechanism according to how often the data is requested and how quickly it needs to be available. For example, it might make sense to store search indexes on a fast disk but archived web content on a slower disk.
• Store shared content such as user-generated comments in a clustered storage. This allows various Magnolia instances to access the same comments. See Clustering for an illustrated example.
• Integrate your system with an external repository. As long as the external repository adheres to the JCR standard, Magnolia can access content in it.

The changes you make to nodes and properties are transient in the workspace. Only when the system performs a workspace save operation are the changes persisted into permanent storage such as a database.