Sitecore Docs - Tech Tips by GS

The Problem We were working with Sitecore XP 10.1 using ASP.NET MVC. Our solution had more than 100 Sitecore sites, and all page items and datasource items used the a Base workflow. The workflow was assigned globally through template standard values. However, some sites needed a simpler workflow with fewer states. We decided to introduce a new workflow called Simple Workflow for these sites. The plan was to create a script that would run against the sites requiring the simpler workflow and update the workflow and state fields of their existing items. This would move the existing content to the new workflow. However, there was another scenario to consider. Since the old workflow was still configured on the standard values of all item templates, any new item created on these sites could inherit the old workflow instead of Simple Workflow To address this, we planned to implement a custom processor that would update the workflow of newly created items to match the workflow used by...

The Problem We had a requirement in Sitecore where content authors should not be able to uncheck publishing targets in the Publish dialog. Sometimes, content authors accidentally uncheck the publishing target and then report that publishing is not working. We wanted to avoid this situation by ensuring that the publishing target always remains selected. One option we considered was to deny Read access to the publishing target using Sitecore security. However, our setup had only one publishing target. After denying Read access, the entire Publish button in the Experience Editor ribbon became disabled. This was not the expected behaviour. We wanted to restrict changes to the publishing target selection without affecting the publishing functionality. There are two possible approaches worth considering. Option 1: Hide the Publishing Targets The first approach is to keep all publishing targets selected and hide the target checklist from the dialog. The customization is in the foll...

One of the things I like about SitecoreAI is that you can build a fairly sophisticated page composition model using Page Designs, Partial Designs and Page Branches. But when you start combining all three, there are a few concepts that are easy to misunderstand. I recently worked through one such scenario where we were setting up Page Designs and Partial Designs and ran into questions around: Template to Design Mapping Page Design standard values Page Branch insert options Partial Design datasource locations local:/ versus page:/ Editing datasource content on individual pages Individually, each feature makes sense. The confusion starts when they are used together. The Page Design Structure Our intended structure was something like this: Page Template | v Page Design | +-- Header Partial Design | +-- Content Partial Design | | | +-- Hero Banner | +-- Footer Partial Design The id...

I recently spent some time troubleshooting SitecoreAI Page Branches, and what initially looked like one problem actually turned out to be two different things. The requirement was fairly straightforward: We wanted content authors to be able to create pages using Page Branches directly from Page Builder, without having to manually configure insert options on every page template. At the same time, we wanted the Page Branch to provide the required datasource structure for the components used by the page design. That led to two questions: Why are my Page Branches not appearing as insert options? Why aren't the datasource items being automatically created when a page is created from a Page Branch? The interesting part was that the answers were different. The Original Requirement We had Page Branches configured under: /sitecore/content/mysite/Shared/Presentation/Page Branches The idea was to configure a rule on the Page Branches folder so that a particular Pag...