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...

The Problem Enterprise tech leaders migrating from legacy Sitecore XP or non-headless SXA to SitecoreAI (the SaaS ecosystem centered around XM Cloud) often focus heavily on marketing metrics like the reported 371% ROI . However, executing a modern composable migration requires a sober look at how the underlying cost structures and technical customizations change. Moving to a locked-down SaaS platform changes your operational expense (OpEx) framework and requires you to rebuild years of monolithic code customizations. The Financial Structural Shift Migrating to SitecoreAI eliminates the traditional capital and maintenance costs of a monolithic platform, but it introduces brand-new infrastructure line items that shall not be ignored. 1. Disappearing Costs Backend Topology Maintenance: You completely eliminate the expense of hosting, scaling, and networking 10+ server roles (CM, CD, xConnect, Identity, Processing) across Azure PaaS or AWS VMs. The Upgrade Cycle: The historical burden ...

The Problem Every day, a new Sitecore project is delivered somewhere in the world. Thousands of developers, architects, consultants, and agencies help organizations implement Sitecore. But ultimately, who pays for all of it? The business. How do business stakeholders such as content authors, marketers, product owners, and technology leaders know they received value for their investment? More importantly, how do they know that a Sitecore project delivered at high speed over a few months will not become a long-term maintenance burden once the implementation partner has moved on and the support contract has ended? In theory, having a technically competent person with software architecture experience act as a gatekeeper for the client should be enough. In reality, however, Sitecore is about much more than code. It involves data modeling, information architecture, SEO, governance, content authoring experience, and platform best practices. Sitecore itself contains many concepts that have the...

One of our content authors recently raised a simple question: "Why does the Publish Date in Sitecore Pages show UTC instead of my local time?" Here is what it looks like in SitecoreAI -  It pretty much clarifies that this is an expected behavior and the timezone being shown to user is UTC. But it does not tell what can we do to make it follow local time zone. Understanding the behavior Sitecore stores Date and Datetime values in UTC , ensuring consistency across environments and deployments. When these values are displayed in Sitecore Pages, they are rendered using the server's configured timezone , not the individual author's browser or local timezone . This means: ✔️ Data is stored consistently in UTC. ✔️ Display is based on the server timezone. ❌ There is currently no documented configuration to display dates in each author's local timezone. If your server timezone needs to be adjusted globally, Sitecore provides the following configuration: <setting name=...

When configuring a Sitecore production environment on VMs (on-prem or cloud) , it’s critical to define and open only the necessary network ports between the servers to ensure secure and functional communication between the roles (CM, CD, Solr, SQL, Redis, Identity, etc.). Below is a breakdown of recommended ports that should be opened between VMs in a scaled Sitecore XP 10.x environment : 🔐 Core Port Recommendations Source VM                               Target VM                                         Port(s)                     Protocol                         Purpose                 ...

Sitecore 10.4.1 is finally here! Everyone's excited about the new release—but with every update, sometimes surprises sneak in. And we’ve got one such story for you. This happened on a Sitecore 10.4.0 instance running in an Azure Kubernetes Service (AKS) cluster. One day, a fellow Sitecorian reached out to me and told that things just… broke. The Problem He said it was supposed to be a normal release. A developer pushed changes, the pipeline ran, and then— boom —errors everywhere. So we started looking into it. For your context, we got the below error - The Analysis Our First Guess: Maybe It’s the Code? We thought maybe the issue was in the new Pull Request (PR). We checked the changes, but everything looked okay. Just to be sure, we  reverted the PR  and tried the release again. Same error. Then we tried releasing an  older build  (before the error started). That one worked just fine. So now we knew—this wasn’t caused by code changes. The Solution Soon, w...