We faced this problem recently where publishing a single global datasource item, that lived inside the root
/Data folder resulted in the republishing of the entire site. And it confused us greatly.
Why would publishing a single item result in the entire site being published. Even when we used
Smart Publishing and Subitems and Related Items were switched off. The answer,
while not immediately clear, makes perfect sense when you remember where you are. XM Cloud.
So let’s explore this in more detail.
How Publishing Works in XM Cloud
Unlike traditional Sitecore XP/XM publishing in an IaaS/PaaS environment where content is moved / copied to a separate database from which it is served to users; in Sitecore XM Cloud, there is no separate ‘web’ database. When content is publishing in XM Cloud, the publishing goes a publishing pipeline. That pipeline’s purpose is to convert the items into appropriate objects for Experience Edge. Those objects are referred to as item entities.
To determine exactly what should be published, when an item or site is published by an author, multiple tasks will be performed. Those include:
- Calculating additional entities to publish
- Calculating dependencies
- Resolving dependencies
- Deleting old or expired content
It is under Calculating dependencies that creates the problem we find ourselves in. You see, when a component / datasource is within a Partial Design, any page that uses said Partial Design is effectively considered a dependent. Thus, publishing the datasource forces each page to be published.
It’s not all that uncommon to have a limited number of header or footer partial designs and thus affecting a large number of pages all at once.
Best Practices as Recommended by Sitecore
It’s actually not immediately obvious, at least it wasn’t for me, what the implications and importance of exactly what we link to in our datasources can impact the publishing process. Sitecore even has recommendations as to this, found here: Experience Edge for XM best practices.
The first recommendation is quite clear:
Do not put global data in the Layout Service output for pages
But why exactly? You see, when we were publishing what seemed like an innocent rich text datasource, it was actually the datasource of a component that existed inside the Partial Design for the header placeholder for every page on the site. Traditionally this wouldn’t have caused any issue what so ever, but in XM Cloud, by updating and publishing the datasource it walks that relationship back up and the layout service then determines every page that uses that Partial Design and subsequent datasource needs to be updated.
How Do We Avoid Publishing Everything?
Before we can answer that we have to understand precisely why we might not want to. In our case, the content author is trying to update and publish the rich text value for a banner that would appear at the top of every page. In the early days, there wasn’t workflow present on items. As such, by publishing this one item, pages that aren’t ready or shouldn’t be published were getting published accidentally.
You might think, and accurately so, that workflow would prevent the publishing for said pages. And that’s true to a degree. You see workflow would only prevent the changing of the components on said page. It wouldn’t care if one datasource had it’s values changed. As a result, even a previous version that linked the same datasource, unless that datasource had workflow on it as well.
One Solution: Workflow, Workflow, Workflow
Knowing all of that, I would say it’s one of the most important things in XM Cloud. Working in XM Cloud without workflow on pages let alone datasources is something I would consider reckless. This would ultimately set a content author to accidentally publish something they aren’t intending.
But how to do this without it being cumbersome for when an author wants to work in Pages. The answer is
taking advantage of a Datasource Workflow Action.
What is a Datasource Workflow Action?
So precisely what is this and how do I use it? So a Datasource Workflow Action is something, l when
using SXA, you can navigate to your workflow under /system/Workflows and on an action, such as
Submit, right click and select Insert and click Datasource Workflow Action.
Once you’ve done that, you’ll need to fill in four field. They are as follows:
Command Item- Determine the appropriate workflow state that the items should be moved toScope- Whether this impacts child or descendantsExecute on items that pass this rule or any item if empty- Determine the rules for which the item will meet this conditionExecute on data source items that pass this rule or all data sources if empty- Determine the rules for which apply to the datasource. e.g. A specific component type
It should be noted that this does NOT apply to global datasources but rather local datasources.
Another Solution: Indirect Datasources
In our case our client wanted the ability to adjust the rich text in an alert banner without having to publish everything, and thus ensure something didn’t accidentally get published. But also, speed up publishing.
Thus we have removed our datasource, and instead use an ENV variable to load in the the datasource location in the
getStaticProps. We do this because that item allows our client to select multiple options. It’s not a
necessity. You could point that ENV variable directly to your datasource but you could encounter caching of the
component if you’re not careful.
When we load the component, in a useEffectwe identify the item, and using GraphQL, load the appropriate
data and inject it into the component. There are some drawbacks to this approach as you can have design draw
artifacts. The other is that you are really unable to take advantage of caching.
I think that you’ll find, while this can be somewhat confusing in the beginning, once you understand why it happens you’ll be able to resolve them and likely find a variety of ways of solutioning a way around it.
Navigating Sitecore XM Cloud Publishing
In conclusion, understanding the intricacies of the publishing process in Sitecore XM Cloud is essential for managing your content effectively. By grasping the relationship between components, datasources, and the layout service, you can avoid unintended site-wide publications and optimize your workflow. Implementing strategies such as workflow enhancements and utilizing indirect datasources can significantly mitigate risks while improving the efficiency of your publishing operations. Embrace these best practices to ensure that your content updates are precise, controlled, and aligned with your organizational goals.
