Problem

While working on a current content project in Sitecore 10, I encountered a frustrating issue: when removing a component that contains a placeholder, Sitecore deletes only the parent rendering but leaves all nested child renderings behind in the layout field (__Renderings). As a result, orphaned components are created. They will never be rendered but still remain in the item’s layout, leading to unnecessary clutter, rendering issues, and potential performance degradation.

When working with Sitecore’s dynamic placeholders, child components are often assigned within parent renderings. However, if a parent rendering is deleted, Sitecore does not automatically clean up the child renderings that were nested inside its placeholder. 

These orphaned components:

• Remain stored in the layout field (__Renderings).
• Are not visible on the page, even though they still exist in the data structure.
• Can cause broken layouts, unused placeholders, and excess rendering data.

Solution

So, how do we clean up these orphaned renderings? Let’s dive into the fix.

As part of the solution, we implemented an event handler for item:saved to validate whether a rendering with a nested placeholder was removed, potentially leaving orphaned renderings. If orphaned renderings are detected, they are removed, and the layout field is reserialized.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using Sitecore;
using Sitecore.Data.Fields;
using Sitecore.Data.Items;
using Sitecore.Events;
using Sitecore.Layouts;

namespace YourNamespace.Sitecore.Events
{
    public class DeleteOrphanRenderingsHandler
    {
        private const string DefaultDeviceId = "{FECA918C-40C4-4F99-8CF6-BE64DAF8FC32}"; // Default Sitecore device ID
        private const string PlaceholderFormat = "-{0}-"; // Format for placeholders in Sitecore
        private const string LocalDataSourcePrefix = "local:"; // Prefix for local data sources

        public void OnItemSaved(object sender, EventArgs args)
        {
            if (!(Event.ExtractParameter(args, 0) is Item savedItem) ||
                !(Event.ExtractParameter(args, 1) is ItemChanges itemChanges) ||
                itemChanges.IsEmpty)
            {
                return;
            }

            foreach (var fieldId in new[] { Sitecore.FieldIDs.LayoutField, Sitecore.FieldIDs.FinalLayoutField })
            {
                if (!itemChanges.FieldChanges.Contains(fieldId))
                    continue;

                // Important check: If Context.Item is null, local data sources may break (render empty)
                if (Context.Item == null)
                {
                    Context.Item = savedItem;
                }

                var updatedField = itemChanges.FieldChanges[fieldId];
                var updatedFieldValue = updatedField.Value;
                var originalFieldValue = updatedField.OriginalValue;

                if (string.IsNullOrEmpty(originalFieldValue) || string.IsNullOrEmpty(updatedFieldValue))
                    continue;

                var originalLayout = LayoutDefinition.Parse(originalFieldValue);
                var updatedLayout = LayoutDefinition.Parse(updatedFieldValue);

                var deviceId = Context.Device?.ID.ToString() ?? DefaultDeviceId;
                var originalDevice = originalLayout.GetDevice(deviceId);
                var updatedDevice = updatedLayout.Devices.Cast<DeviceDefinition>()
                    .FirstOrDefault(x => x.ID == deviceId);

                if (updatedDevice == null || originalDevice == null)
                {
                    continue;
                }

                var updateLayoutField = (LayoutField)savedItem.Fields[fieldId];
                
                var originalRenderings = originalDevice.Renderings.Cast<RenderingDefinition>().ToArray();
                var updatedRenderingsFromLayout = updateLayoutField.GetReferences(Context.Device).ToList();

                var removeResult = RemoveOrphanedRenderings(originalRenderings, updatedRenderingsFromLayout);
                if (!removeResult.wasUpdated) continue;

                var mappedRenderings = removeResult.updatedRenderings.Select(x =>
                {
                    var dataSourcePath = x.Settings.DataSource;
                    return new RenderingDefinition
                    {
                        UniqueId = x.UniqueId,
                        Placeholder = x.Placeholder,
                        ItemID = x.RenderingID.ToString(),
                        Parameters = x.Settings.Parameters,
                        Datasource = ConvertToLocalDataSource(savedItem.Paths.FullPath, dataSourcePath)
                    };
                }).ToList();

                updatedDevice.Renderings = new ArrayList(mappedRenderings);
                
                savedItem.Editing.BeginEdit();
                // If we use LayoutField.SetFieldValue(), the layout will be missing for the item.
                savedItem.Fields[fieldId].Value = updatedLayout.ToXml();
                
                // Prevent second item:save event
                savedItem.Editing.EndEdit(true);
            }
        }

        private static (bool wasUpdated, List<RenderingReference> updatedRenderings) RemoveOrphanedRenderings(
            RenderingDefinition[] originalRenderings,
            List<RenderingReference> updatedRenderings
        )
        {
            var wasUpdated = false;
            var removedRenderings = originalRenderings
                .Where(orig => updatedRenderings.All(updated => updated.UniqueId != orig.UniqueId))
                .ToList();

            if (!removedRenderings.Any()) return (false, updatedRenderings);

            foreach (var removedRendering in removedRenderings)
            {
                var updatedRenderingsTemp = updatedRenderings
                    .RemoveWhere(x => x.Placeholder.Contains(string.Format(PlaceholderFormat, removedRendering.UniqueId))).ToList();

                if (updatedRenderingsTemp.Count != updatedRenderings.Count)
                {
                    wasUpdated = true;
                }

                updatedRenderings = updatedRenderingsTemp.ToList();
            }

            return (wasUpdated, updatedRenderings);
        }
        
        private static string ConvertToLocalDataSource(string savedItemFullPath, string absoluteDataSourcePath)
        {
            if (string.IsNullOrEmpty(savedItemFullPath) || string.IsNullOrEmpty(absoluteDataSourcePath))
                return absoluteDataSourcePath; 
        
            if (absoluteDataSourcePath.StartsWith(savedItemFullPath, StringComparison.OrdinalIgnoreCase))
            {
                var localPath = absoluteDataSourcePath.Substring(savedItemFullPath.Length).TrimStart('/');
                return $"{LocalDataSourcePrefix}{localPath}";
            }
            return absoluteDataSourcePath;
        }
    }
}

The configuration file should be placed under the App_Config folder, following your project’s folder structure. If you are using the Helix architecture, I recommend placing it under App_Config/Include/Foundation

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <events>
      <event name="item:saved">
        <handler type="YourNamespace.Sitecore.Events.DeleteOrphanRenderingsHandler, YourNamespace.Sitecore"
                 method="OnItemSaved" resolve="true"/>  
      </event>
    </events>
  </sitecore>
</configuration>

Some Interesting Moments from the Code Above

Set Context.Item to the current saved item manually

When handling Sitecore’s item:saved event, Context.Item is not automatically set to the saved item, even if resolve="true" is specified in the configuration file. This leads to issues when resolving local data sources (e.g., local:/Data/RichTextDatasource) because Sitecore relies on Context.Item for resolution.

Without explicitly setting Context.Item, the following problem occurs:

• updateLayoutField.GetReferences(Context.Device); loads local data sources as empty strings (“”).
• All renderings that had local data sources will lose their assigned values.
• This causes unexpected behavior and potential errors on the website.

Fix: manually set Context.Item

To ensure correct resolution, manually set Context.Item before processing:

    if (Context.Item == null)
    {
		    Context.Item = savedItem;
    }

Using direct field set instead of LayoutField.SetFieldValue()

Using LayoutField.SetFieldValue() was found to remove the assigned layout, preventing the page from rendering properly.

savedItem.Editing.BeginEdit();
savedItem.Fields[fieldId].Value = updatedLayout.ToXml();

// Prevent second item:save event
savedItem.Editing.EndEdit(true);

ConvertToLocalDataSource function

Datasource = ConvertToLocalDataSource(savedItem.Paths.FullPath, dataSourcePath)

The ConvertToLocalDataSource function was introduced to convert absolute data source paths to local relative paths when possible. This helps simplify the maintenance of data source items, especially when the parent item is renamed, ensuring that data sources remain correctly linked.

Purpose of this function

• Converts absolute paths (e.g., /sitecore/content/Home/Data/Item) to local paths (local:Data/Item) when applicable.
• Ensures that data sources remain correctly associated with their parent item.
• Prevents issues where renaming a parent item breaks hardcoded absolute paths.

This approach helps keep data sources flexible and reduces the risk of broken references when items are moved or renamed in Sitecore.

P. S.

Thank you for reading! I’m planning to share more about the challenges I encounter in Sitecore development. Stay tuned for more insights!

I have been working with Search in Sitecore for more than four years with different engines, including SOLR, Lucene and Azure Search (this is not to be confused with Azure ElasticSearch, because in version 9.2, Sitecore didn’t have an SDK to work with this one).

By this time, I’ve touched upon different scenarios of Search implementation:

• Supporting both Azure Search and SOLR at the same time
• Integrating third-party tools to provide data for a custom index
• Covering all CRUD functions for Custom Index crawler
• Increasing performance for the custom Index full-rebuild logic
• Implementing cloud solutions for incremental index update
• Creating a tool to manage search results on the website according to different criteria (dates, events, filters)

It was a long journey and tons of challenges, and I will be happy if some tips from this and my future blogs will save your time during planning or troubleshooting.

The Search functionality is an important feature on many websites related to content management (literally, it means almost all Sitecore-based websites). And in my experience, indexing/search logic was sometimes really complicated and required a deep understanding of what you could do with the available tools set.

What is the first step in all systems that requires Search?

The first and most important step is to collect as many search-related requirements as possible. Otherwise, it’s hard to design a schema and choose the Search engine if you don’t know how it will be used. To clarify versions, we started our project on Sitecore 9.2 because it was the latest one at that moment.

The customer wanted to use Azure Cognitive Search on production, and this was the first issue we faced, because (as we learned later) the project turned out to be complicated in terms of the search business logic. For some reasons, we couldn’t pull together all the requirements on time. So eventually, we selected Azure Cognitive Search for all shared environments (Dev, QA, Staging and Production) and SOLR for local environments.

It was a mistake for several reasons:

1. It took additional time to support several Search Engines.
2. As mentioned above, the search functionality caused performance bottlenecks (will be described later).
3. Some bugs were reproduced only on Azure Search or SOLR.
4. Different limitations from both system took time to deal with.
5. Local testing/development.
6. Sitecore SDK for both works differently when using Search.

As you can see, it was a pretty bad idea trying to mix it all. But we were brave enough to try it.

Azure Cognitive Search limitations

Here I will try to show all limitations that can affect your work during the project life.

1. An Azure Cognitive Search index can only contain up to 1000 fields. It means that all your fields + all fields that will be created (multi-language fields (1 field for every original field for one language), system fields) are limited by 1000. This is not much at all.
2. Joining queries such as .GroupJoin(), .SelfJoin(), and other operators that join queries, is not supported and results in an error. For our case, it was mandatory to have Group operations on the Search Server side. While the Azure Search was exploited on the website, the Search response could take up to 15 seconds(!!!) because group operations were performed on the Server side instead of the Search engine.
3. Some weird behavior for equaling string operations. It turned out that getting only equivalent results to the specific string is not supported on the Azure Search LINQ Query converter level. The reason is converting the .Equals() LINQ function into Azure search query.

Here, if the expression is string and the trimmed expression length isn’t equal to 0, this._queryBuilder.SearchQueryBuilder.Equal will be used. Let’s take a look what this method contains inside.

It contains typical Contains() function in the {fieldName}:(“{value}”) format.

You can invent something with different types (e.g., double, integer) as a workaround. This is the first signal that should make you consider the migration to the different Search Engine.

More limitations you can find here.

Azure Cognitive Search advantages

At the same time, Azure Cognitive Search has advantages too:

1. It’s powered by Azure, meaning that you can integrate search into different Azure apps.
2. It has 99.9% SLA, which is important for the production environment.
3. It’s easy to configure auto-scale.
4. It works pretty good for simple Search solutions.
5. Due to the fact that it’s a SaaS solution, it’s pretty easy to set up.

But these advantages could not outperform challenges that we faced, and finally, we switched from Azure Cognitive Search to SOLR, which made our solution easier to support and increased performance multiple times.

P.S.

In my following blog posts, I want to describe how we created the SOLR custom index, what issues we faced, and how we built the Full-Rebuild process. Stay tuned and try to avoid big challenges instead of fighting with them.

In this article, I’ll talk about our experience of participating in this event and the technical result we managed to achieve.

Why Participate in Hackathon

In 2020, I intended to compete in Hackathon but things didn’t work out. Why? My colleagues and I had a brilliant idea (which we’re still working on so I can’t disclose the details) but we couldn’t gather together at the appointed time and implement it. I guess first attempts often result in failure.

This year, when I saw the announcement for Sitecore Hackathon 2021, I decided to give it another go.

Hackathon is a good challenge for every developer. If you take part in this event, you can:

• gain new experiences
• get new ideas
• network with like-minded people
• get energy and motivation for creative and productive work.

In fact, it was my team who really inspired me to participate. I was sure that together with my talented and creative colleagues Vitali Taleika and Vadzim Papko we would achieve great results.

Discussing Ideas

Since we didn’t know the Hackathon topics for this year, we could only discuss potential ideas that we were not sure would feature in the competition.

We spent a lot of time discussing the potential solutions we could implement, and we had some great ideas, but all of them required weeks or months of intensive work to be completed. This was clearly not appropriate for the bounds of a 24-hour marathon.

On March 5, we gathered together for the start of Hackathon (at 3 a.m. our local time) and learned that the following topics would feature:

• The best enhancement to the Sitecore Admin (XP) for Content Editors and Marketers
• The best enhancement to SXA
• Best use of SPE to help Content Authors and Marketers
• Best use of Headless using JSS or .NET

We were finally able to make a decision on which module to implement. Since all of us are experienced in Sitecore search functionality, Vitali Taleika suggested we work on improving the keyword synonym search for SOLR using Sitecore tools.

After some discussion, we agreed that it would be a very useful module for the Sitecore platform. We also thought that with our idea we could try to win in the category “The best enhancement to the Sitecore Admin (XP) for Content Editors and Marketers.”

Implementation

As we ensured that our idea complied with all the requirements, we started to brainstorm how to implement it. The task was not hard because everyone in our team has a deep understanding of search functionality.

We discovered that the SOLR engine utilized the “synonyms.txt” file to get the necessary data. But there was no way of managing this useful function from Sitecore. We also found Sitecore Pipelines responsible for synonym management in SOLR.

By then, we had a plan on how to integrate a flexible synonym management approach in SOLR using Sitecore tools and make it manageable by the Content Author.

We implemented our idea in the following way:

• A content author fills in Sitecore items with the necessary synonyms in the content tree.
• All specified synonyms are migrated to SOLR with the help of a custom Ribbon button.
• The search can now be performed using specified synonyms.

In Sitecore, Content Author has two types of items. The first type is root settings for SOLR that contain Core names that should be applied with synonyms. You can see the structure below:

The second type contains synonyms that get published to the SOLR engine.

Below you can see our custom Ribbon, which triggers the sync with Solr synonyms:

When all synonyms are synchronized, we can show how the feature works. Let’s search for the word “superman”. We defined this word in the synonym content item, but search pages don’t contain it.

Here are two pages that contain a “superman” synonym. Let’s open the Contact page.

Here you see the word “MVP” but no “superman”. This is how the search-by-synonyms functionality works: a page may not contain the specified word but it will be in the search results if it contains a synonym for that word.

You can find the source code and documentation on how this module can be used on your website in the GitHub of our hackathon team.

Preparing for the Demo

The hardest task for us at this Hackathon was to prepare the demonstration website for our module.

We spent half of the allocated time (9–11 hours) looking for a demonstration website with pre-filled content and implemented search functionality. That’s quite a long time, isn’t it?

During this time, we could have created our own personalized website with enough content for any purpose using SXA. Unfortunately, that idea came to our minds too late, after we had already spent 6–7 hours searching for and installing available demonstration websites from Google.

Imagine our disappointment when we realized that the website we had installed was working well but was not compatible with our module, because its searching approach was not the one we needed. This was a moment of heartbreak for us.

I invite you to learn from our mistakes and create a website that will be appropriate for your purposes. And don’t hesitate to ask colleagues from the Sitecore Community in Slack or Twitter chats if you have questions that you can’t resolve yourself during the Hackathon.

Tips for Future Hackathons

During this Hackathon, we made a number of mistakes that prevented us from performing better. But as they say, experience comes from bad experiences. Next year, we’ll use the following tips to avoid serious obstacles:

1. Concentrate on what’s really important. We were not concentrated enough and wasted a lot of time on issues that were not critical for our module.
2. Sleep at least 3–4 hours. There is no need for you to stay awake for 24 hours. If you sleep a bit, you will reload and be more effective.
3. Prioritize the Hackathon task over other tasks. You must put aside all your non-Hackathon plans to be fully involved in the process.
4. Don’t waste time searching for the demonstration site. It’s more efficient to create your own demonstration website that will be relevant for your team and your idea.
5. Eliminate negative emotions, only fun, and Rock’n’Roll 🙂

To Sum Up

It was really exciting for me to be a part of this event. I realized that the Sitecore Community is a big family passing positive energy to its members when they need it most.

In addition to the module development, I had much fun networking with the community members via Twitter and Slack. Many warm and friendly people were ready to help us with any issues and ideas. This made me feel good.

Undoubtedly, I will take part in Sitecore Hackathon next time and will do my best to perform better than this year.

If you have any questions, contact me via Twitter or LinkedIn.