Dependencies and publishing

What 'dependency' means in the context of publishing

Many items rely on other items to function correctly. These relationships are known as dependencies. These dependencies can be used during publishing to determine which additional items should be included in a publishing operation.

A dependency relationship exists when any item contributes to the published output of another item. For example, a page might use a datasource item to provide content, or it might reference other items that supply settings, layouts, or content used during rendering. Publishing can take these relationships into account to help ensure that all required content is available in the target environment.

When an item is published to Edge, its dependencies are calculated. Some items may contain 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 has a dependency on the template. If the template changes, all its dependent items need to be republished.

Some components create dependencies when used in a page layout:

• Partial designs - any page that uses a partial design is its dependent.

• Publishing groups - all the items in a publishing group are dependents of each other.

Calculating and resolving dependencies

When you publish an item, the system queries Edge and the master database 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. If you are using smart publishing, any items identified as a dependency are included in the publication only if their revision id has changed. If you are republishing, the item and all its dependencies will be published, regardless of whether they have changed. The process repeats until no new publishable items are found.

Dependencies are calculated at item level, so it isn't possible to determine which changes cause an item to be published. 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 will be republished if you are using snapshot publishing. However, if you are using Edge runtime publishing, the pages will not need to be republished because they have a reference to this data source.

The ExperienceEdge.ComputeContentDependencies setting controls whether dependencies are computed for items referenced in supported link and list field types during the publishing process. This setting is disabled by default. When enabled, referenced items are stored as dependencies so that publishing a changed referenced item can also republish the dependent item. After enabling or disabling this setting, you must republish the site so that dependency data is recalculated for all items in Experience Edge. This setting can also be configured using an environment variable (Sitecore_ExperienceEdge_dot_ComputeContentDependencies).

Experience Edge Connector calculates dependencies between Sitecore items during publishing in two phases.

1. The Compute phase — When an item is published, dependency metadata is written onto the item's entity metadata (stored on Edge or in the metadata provider). This records what the item depends on.

2. Resolve phase — At publish time, the stored metadata is queried in reverse to find all items that depend on the item being published. Those dependent items are added to the publish manifest.

This creates a bidirectional dependency graph: the compute phase writes "Item A depends on Template X", and the resolve phase answers "which items depend on Template X?" by searching metadata.

Dependency depth

Dependencies can exist at multiple levels. Some dependencies are direct references, where an item references another item directly. Other dependencies are multi-level references, where an item references another item that in turn references additional items. Publishing can follow these relationships to identify related items that may need to be considered during a publishing operation.

When publishing evaluates dependencies, it can traverse these relationships to identify related items. As the number of relationship levels increases, the dependency chain becomes deeper. The publishing behavior for these dependency chains can be affected by the publishing options and configuration settings that are used.

How publishing settings affect dependency behavior

One setting that affects dependency behaviour is Publishing.DeepScanRelatedItems. When enabled, this setting recursively includes multi-level referenced items in the publishing process; when disabled, only direct references are included.

Publishing.DeepScanRelatedItems interacts with the Publish related items setting. When Publish related items is enabled, Publishing.DeepScanRelatedItems controls how deeply the system scans for related items during publishing.

When Publishing.DeepScanRelatedItems is set to true, the system recursively collects all related items: first gathering items directly referenced by the given item, then items referenced by those items, and so on down the chain. When set to false, only directly referenced items are included as related items.

Other publishing configuration settings that affect dependency behavior include ExperienceEdge.IncludeDependencyAncestors, ExperienceEdge.ComputeContentDependencies and ExperienceEdge.LinkDependentTypes.

How dependencies affect publishing outcomes

The interaction between smart publish and versioned content can sometimes cause published items to not appear on your site, particularly if their structure features deep linking (where items are connectected through multiple levels of references, creating deep dependency chains). This affects content published in either snapshot or Edge runtime publishing. For more detail, and how to prevent this, see Issues caused by deep linking.