Publishing content to the live repository

The publication service allows you to transfer content from staging modes (Edit and Contribute modes) to the live repository to make it available for end users. This topic describes the publishing process, staging and live workspaces, and how Jahia handles versioning changes between the two workspaces. The topic also describes the publication service and its algorithm.

Publishing in the Jahia UI

About the Publish, Publish all, and Publish site options

Publication can be triggered by using the publication menu, with the different options:

• Publish currently selected node
  This option will publish the selected node and its subnode stopping when encountering a node marked has having a different publication process (by default pages have different publication processes).
• Publish all under currently selected node
  This option will publish the selected node and its subnode and will not stop on any node so it will publish the whole subtree.
• Publish all sites
  Publish the complete site, with files and contents.

In all cases, the content is published only in the current language.

Unpublishing content

Mark the selected node has not published anymore (marking it as not valid in live repository).

Showing the publication status of content

The show status option displays detailed status for the current page, showing which content has been modified or need publication.

Each content has its own individual status, as shown when displaying publication status or in the publication dialog :

• Published
  The content is currently published and unmodified
• Modified
  Staging content has been modified
• Not published
  Content has never been published yet
• Mandatory language required
  Mandatory content has not been filled in a mandatory language - cannot publish
• Conflict
  Different content with same name already exists - cannot publish
• Unpublished
  Content has been unpublished
• Marked for deletion
  Content will be deleted when publishing

About the Publication manager

This popup a window displaying the tree of nodes having different publication process (by default only pages). For each node you will see its status (including status of subnodes as an aggregate of the node status). If you can start a publication on the node the checkbox will be active.

Publication dialog

When starting a publication, a dialog appears. If a workflow is available, the first tab “action” and second tab “comments” lets you fill information that will be passed to the reviewer. The tab “publication infos” display the list of all items that are being published, with their current status. You can start the workflow or use “bypass workflow” to publish directly, if you’re allowed to do it.

Publication workflow

A workflow is associated to “publish” and “unpublish” action, and allows another user to review the publication before actually doing it. You can change the workflow at any level of the page tree by using the “workflow” tab.

Implementation

Workspace concepts

Workspaces are a JCR concept - a workspace is a persistent data store, containing all nodes and properties. Jahia defines two workspace - live and default. These two workspaces may contain the same nodes, but in different versions - each node has a version in default and/or a version in live. Content nodes are created in staging before going live. Publication service is responsible of copying content from default to live and maintaining the different versions.

Versioning concepts

Every versioned node has a version history node, which is stored in a special store, visible from all workspaces. This version history contains all node versions since the creation of the node. If a node exists in a workspace, it points to one specific version in the history. Each version has predecessors and successors.

New versions are created when “checking in” a node : a new entry is created in the version history, the previous versions is set as a predecessor, and the content of the node is copied into a “frozen node” under the version.

When a node is published, one version is created in default, the changes are applied to the live node, and a version is created in live. There are 2 parallels linear history, one per workspace.

Publication nodes tree

When the user asks to publish a page, Jahia gather the status of all sub-nodes in the same publication process and displays it in the “publication infos” tab. Nodes that have the “jmix:publication” mixin are marked as being part of another publication process. By default, pages, files and folders have this mixin.

The JCRPublicationService.getPublicationInfos() is responsible of building this tab - it returns the list of nodes to publish and their status, depending on the parameters being passed.

• uuids : the list of identifiers from which the publication starts (page id, for example)
• languages : the list of languages to publish , null for all languages
• includeReferences : whether or not to include the referenced nodes
• includeSubnodes : go down to the tree, stopping at nodes which are in a different publication process (nodes with jmix:publication mixin)
• allsubtree : go down into the whole sub tree, including jmix:publication nodes (requires includeSubnodes=true)
• sourceWorkspace : “default”
• destinationWorkspace : “live”

This returns a PublicationInfo object, containing the tree of objects to publish, including the references if includeReferences was set to true. The getAllUuids() can be used to get all individual ids to publish.

About the publication algorithm

The publication is done by calling the method JCRPublicationService.publish() method, with the following parameters :

• uuids : the full list of individual node ids to publish - usually returned by the getPublicationInfos() method
• sourceWorkspace : “default”
• destinationWorkspace : “live”
• checkPermissions : whether or not to check the “publish” permission for the current user on each node
• updateMetadata : updates the publication metadata (usually true, except when importing content)
• comments : publication comments

The publication service will then do the following:

• Retrieve all nodes to publish
• Updates metadata : j:published, j:lastPublished , j:lastPublishedBy
• Remove nodes marked for deletion in both default and live
• Clone nodes that have never been published in live
• Merge existing nodes in live using the ConflictResolver class
• Create versions and labels