Workspace

A workspace is a subsection of Jahia’s content repository (Content Repository). Jahia uses two. In default, editors create, edit and preview content. Live holds the published content that visitors see. Publication moves the approved version of a content item from the first to the second.

Definition and how it works

Keeping default and live apart lets a team work on the production site without visitors seeing the work in progress. You write, correct, get a review and preview the page as it will appear. The public site only changes at publication, which can be governed by a content workflow. For content, there is therefore no need to go through a separate staging environment. Code and modules, on the other hand, are tested outside production.

The default workspace is also called the edit, preview or staging workspace. It stores all content before it is published. In live, the published version is used to generate public pages. The same content item can therefore exist in two states, its working version in default and its published version in live. The work in progress status keeps content from leaving default until it is removed. On the technical side, queries, including GraphQL API queries, can specify which one they target. If they do not, default is used.

Academy documentation: technical overview of Jahia, default and live workspaces

Workspace vs content repository: the differences

A workspace divides the repository by publication state. It should not be confused with an environment (development, staging, production), which is a separate installation of the platform.

Workspaces and related concepts
Concept	What distinguishes it
Content Repository	The repository stores all content. In Jahia, it is organized into workspaces, then sites. Developers also call it the JCR.
Default workspace	The space where content is edited and previewed before publication. It is one of the two, the other being live.
Work In Progress	A status that prevents content from moving from default to live until it is removed.

Workspace in practice

A live product page must be updated before an announcement. The editor changes the page. The changes are saved in default. Visitors keep seeing the published version, served from live. On announcement day, publication moves the new version online.

For those few days, the page exists in two states at once, with the new version in default and the old one in live. Nobody needed a separate environment to prepare it.

Frequently asked questions

Do we need a separate staging environment to prepare content before publication?

For content, not necessarily. The default workspace lets teams write, review and preview directly on the production platform without exposing anything to visitors before publication. A staging environment remains useful, however, for testing code, modules and version upgrades before deploying them to production.

Why does the preview sometimes differ from the public page?

The preview and the public page do not read the same workspace. The preview shows the working version stored in default; the public page shows the published version in live. An unpublished change, work-in-progress content or an unpublished language can explain the difference. Check the publication state before concluding there is a rendering problem.

Does a comment or form submitted by a visitor go through the default workspace?

No, it takes a different path. What visitors create and is stored in the repository, such as a comment or a form submission, is saved directly in the live workspace, under a page or content item that was published beforehand. This is a logical exception to the usual flow. Visitors have no access to editing interfaces, so they never go through the working version.