Publishing to Experience Edge
When you create a website with Sitecore, you create various types of content items. These items are published to Sitecore Experience Edge as web pages, site layout, navigation, and other elements; you render your website by using a lightweight JSS front end that consumes its content from Edge.
The following diagram illustrates the publishing pipeline:
Best practice: Workflows
We strongly recommend implementing workflows to control publishing. If you rely on manual publishing instead, you might accidentally publish content before it's ready. The following sections explain how dependencies can cause items to be published unintentionally, which you can prevent by implementing workflows.
Using workflows, you can:
-
Control which content is published to Edge, and ensure it's only published when it's ready.
-
Set up flows for content review.
Selecting content
Sitecore offers several options for selecting the content to publish. Each option has different implications for the publishing pipeline and its performance.
Single item publishing
There are two types of publishing for single items: Republish and Smart.
-
Republish - the item will always be published.
-
Smart publish - each item has a revision ID that, by default, is updated whenever changes to that item are saved. With Smart publish, Sitecore compares the revision ID of the item on the content management instance to the revision ID of the same item item in Edge. If both revision IDs are the same, the item isn't published.
In addition, you can choose to publish all the subitems (children) of an item.
Publishing all items
You can publish all items by selecting the Publish Site option in Content Editor. When doing so, there are three types of publishing available:
-
Incremental publish - publishes changed items, based on the history of changes made to items. This is usually the most efficient way to publish all changed items.
-
Smart publish - publishes changed items, based on the revision IDs of each item. This type of publishing can take longer, because it scans the entire item tree, not the list of saved changes.
-
Republish - republishes all items in the content tree.
The publishing pipeline
The main purpose of the publishing pipeline is to convert the content management (CM) items that were selected for publishing into Edge entities. After receiving confirmation from Edge that an item was successfully received and published, the CM updates the published item counters. The publishing pipeline performs the following tasks to create an accurate snapshot of the content available for publishing from the CM instance:
-
Calculating additional entities to publish
-
Calculating dependencies
-
Resolving dependencies
-
Deleting old or expired content
Calculating additional entities
All published content items are considered item entities in Experience Edge, available in the GraphQL API using the path or item ID. Additional item types might be available:
-
Media - additional media-specific properties.
-
Site - SXA site-specific properties, and the sitemap.
-
Page - the page layout.
-
Template and Field - template or field-specific properties.
Calculating dependencies
When an item is published to Edge, dependencies are calculated for the item. These dependencies are stored as queryable metadata on the published entity. Depending on the item being published, there might be a large number of dependencies; for example: a simple page item is dependent on every data source it includes. Another example is a template item; every item in the site that inherits from the template is a dependency of the template.
Also, some SXA components create dependencies when used in a page layout:
-
Partial designs - any page using a partial design is a dependent of the partial design.
-
Widget - any page using a widget is a dependency of the widget.
During single item publishing, ancestor items of local data source items are also published to Edge by default, which can slow down the publishing. You can disable the collecting of ancestors by creating a patch file that sets the ExperienceEdge.IncludeDependencyAncestors setting to false. This setting is in the \App_Config\Modules\ExperienceEdgeConnector\ExperienceEdgeConnector.config file.
Resolving dependencies
When you publish an item, the system queries Edge to find all other items that depend on that item, and adds them to the publishing pipeline. Because these items are being published, all items that depend on the new items are also published. Any items identified as a dependency are included in the publication, regardless of whether they have changed. The process repeats until no new publishable items are found.
Dependencies are calculated at the item level. For example, you might change a data source item of a page in the navigation. Because the page is dependent on the data source item, and is rendered by the navigation component, any page containing the navigation component has to be republished. Currently, it isn't possible to determine which changes cause an item to be republished.
The dependency resolution process is one of the main reasons to implement workflows: it's possible for one user to make a change that causes a page another user is working on to be published. Even a simple two-step workflow consisting of Draft and Publish statuses is sufficient to ensure a website only shows completed content.
Smart publish determines which item to publish before calculating dependencies . This allows it to skip items and their dependencies if nothing has changed.
Deletion
When publishing children of a parent item (subitems), the publishing pipeline compares the child items on Edge with the items in the CM. If an item is found on Edge that isn't in the CM, the item and its children is deleted from Edge. An automatic deletion can also be triggered when running an incremental publish, because it relies on the change history, which includes the deletion in the CM.