How to troubleshoot a common component-based publishing issue in Sitecore
By: Solution Architect Grant Bartlett
A brief overview of legacy publishing in Sitecore and a look at Valtech’s approach to overcoming a common component-based publishing issue.
Since Sitecore 6 was introduced, Sitecore builds have evolved from a form-based page template approach whereby all content on the page was mostly stored in a single Sitecore item (which typically was also the item that represented the page), to a component-based architecture whereby a single page is composed of multiple items, all of which contain their own content.
The next generation
This evolution was supported by an enhanced page editor mode and meant that page template counts were no longer a measure of build complexity, since a single page template could be used to create an entire site. The page function was differentiated simply by the choice and combination of components added to the page. It also afforded greater reuse of content across pages as components on different pages could point to common datasources.
This architectural shift also highlighted a challenge with Sitecore’s workflow pattern since a page went through workflow independently of other items referenced on the page. In other words, with the shift to a component-based model, workflow applied to a page supported approval and publication of the page, but it would not encompass any of the component datasources referenced on the page..
Since component datasources now comprised the lion’s share of a page’s content, this created a problem. A page could go through workflow and be published, but your content wouldn’t be published since it would need to go through workflow separately.
Introducing related item publishing
Sitecore 7.2 attempted to resolve this issue by introducing related item publishing. With it, any items a page referenced would be published at the same time as the page. That included items from the media library (pictures, documents, etc.) as well as any component datasources referenced by the page itself. Although this did partly overcome the original limitation, it did not fully address the issue.
Related item publishing assumes all referenced or linked items are in their final workflow state, which is often not the case. If a page is approved and moved through workflow, but a core component of that page is still in workflow, related item publishing would have no effect on the core component. The only way to make this work would be to have the content author approve all component datasources referenced by the page before publishing the page itself, otherwise you still have a page that’s been published with no content on it. At the time of writing this post, Sitecore has still not addressed this specific issue.
Getting around the component conundrum
Here at Valtech we’ve introduced custom code to mitigate this issue. Here are the main assumptions and observations that drive the underlying functionality:
- All component datasources undergo workflow
- All pages undergo workflow
- Since a single page can reference many components, the workbox is not easily navigated to identify exactly which components relate to your current page. For usability purposes, we assume that when a content author approves a page for publication, they are in turn agreeing that all components on the page are also ready for publication
In essence, when a page is moved to the final state of a workflow, we have custom code that programmatically moves all components referenced via the page through workflow as well. From there, the related item publishing takes over, publishing the page and all related component datasources.
Have you faced a similar issue with your Sitecore publishing? Tell us about it in the comments.
