Relaxing while a campaign goes live — thanks to previewing scheduled content in advance, authors can confidently verify that everything will appear exactly as intended when it matters most.

Overview

In this blog post I introduce a marketplace app I have recently been working on. The goal of this app is to give content authors the ability to do quality assurance of scheduled content, for example to verify that a banner scheduled to go live at midnight actually appears correctly before it publishes.

In the past, this was easily possible within the Experience Editor by changing the Preview Date and Time.

Unfortunately this functionality is no longer available in SitecoreAI Pages Editor and content authors are left to guess whether their scheduled content will display correctly.

I took this lack in functionality as an opportunity to test out the SitecoreAI Marketplace and built an app, that brings a scheduled preview to the SitecoreAI Pages Editor.

How to use the app

After installing the marketplace app in your SitecoreAI environment, it is available on the top right of your SitecoreAI Pages Editor. Simply click the puzzle piece icon and select the app. Now a new panel should open on the left side of your editor.

The panel includes:

• A date and time picker where you can select a time to simulate in the preview window
• A preview frame, that displays your page with, as it will look at the defined time, with respect to the publishing restrictions
• A tab, where you can directly change the publishing restrictions of content items related to the page
• A tab with technical details, which gives you detailed feedback on which versions are currently visible in the preview frame

How to configure the app

You can find the code repository here: https://github.com/simonhck/timed-preview-marketplace-app

The app can be hosted on any platform that can run Next.js apps. During implementation I tested on Netlify, so the repo already contains the Netlify configuration files.

When you configure the app in ‘App Studio’, make sure to set the Route URL to / and grant API access to ‘SitecoreAI APIs’.

In order to connect the preview to your rendering host, you need to add two configurations - editing secret and rendering endpoint.

This can be done either directly in the env variables of your marketplace app with keys:

JSS_EDITING_SECRET
RENDERING_ENDPOINT

Or if you intend to use the app across multiple environments, a config item can be added to the settings folder of your site with values EditingSecret and RenderingEndpoint.

Technical details

The app relies on some plugin code that you have to integrate into your head app. In the repository, you find it under /target-site-plugin.

Under the hood, the preview goes through several steps:

1. By comparing item versions and their configured publishing restrictions, the app determines which content will be overridden in the preview
2. These overrides are stored in a cookie mapped via the item ID
3. The head app is called within the preview frame
4. Within the head app, the plugin code retrieves the stored overrides and applies them to the layoutData before rendering the page

After these steps, the page is rendered within the preview frame with all overrides applied and all content is shown according to the configured publishing restrictions.

Page router vs App router

This app is mainly tested and built on App router and has been very reliable during my tests.

There is a separate branch in the repo that supports Page router, which I created for a client. However, this setup has been more shaky in my tests and you might need to make some adaptations based on JSS/Content SDK version, you are using on your project.

Next steps / future plans

Editing within the app

To allow the author to make some immediate changes while reviewing time restricted content, I would like to add some kind of editing capability to the app.

Improved handling of app configurations

Sitecore has hinted at an improvement for marketplace apps, that they are working on to give administrators the ability to maintain app configurations directly in the app. This would be the ideal place to put the configurations for the rendering host, which is currently still in env variables or as item in SitecoreAI.

Proper passing of preview parameters

Sitecore has hinted at improved preview capabilities for SitecoreAI, where users would be able to pass certain parameters directly to the preview via URL, including a preview time. Once available, this would make the workaround logic of this app obsolete.

There is no confirmed timeline for this change yet, and it could still be a while before it lands. In the meantime, this app provides a reliable solution that content authors can use today. Even once the native preview parameters arrive, the app will continue to serve as a polished interface for interacting with the preview, just without the need for the override logic under the hood.

Feedback welcome

I’d be happy to hear from anyone who integrated this app into their project or just played around with it.

If you have any feedback or questions, feel free to contact me.

Foto Wesley Tingey on Unsplash

We recently upgraded our XP solution from 10.3.1 to 10.3.3 to support the Solr 9.8.1 upgrade.
Version 9.8.1 was released on March 6, 2025. The previous version has reached EOL and is no longer listed on apache.org.

Our initial plan

We assumed the upgrade would be straightforward:

1. Download Solr
2. Convert the .tgz to a .zip (to install it with the SIF)
3. Install on a new port
4. Create cores
5. Update Solr connectionstring in Sitecore
6. Deploy schema
7. Recreate index
8. Done

The issue

When deploying the schema for master_index, we encountered this error:

<lst name="responseHeader">
  <int name="status">400</int>
  <int name="QTime">0</int>
</lst>
<lst name="error">
  <lst name="metadata">
    <str name="error-class">org.apache.solr.common.SolrException</str>
    <str name="root-error-class">org.apache.solr.common.SolrException</str>
  </lst>
  <str name="msg">Current core has 2048 fields, exceeding the max-fields limit of 2000.  </str>
  <int name="code">400</int>
</lst>

This was unexpected — the upgrade seemed simple at first.

Backgroud

Starting with Solr version 9, they introduced a limit on the number of fields per core (see documentation).

This setting is defined in the solrconfig.xml of each core: {SolrInstallPath}\server\solr\{prefix}_master_index\conf

Solution

Update the configuration to a suitable value, for example:

  <updateProcessor class="solr.NumFieldLimitingUpdateRequestProcessorFactory" name="max-fields">
    <int name="maxFields">3000</int>
    <bool name="warnOnly">true</bool>
  </updateProcessor>

• Restart Solr
• Deploy the schema again
• If the error persists, increase maxFields and repeat the steps

Tip: Start with a high value (e.g., 50,000) and adjust later based on actual requirements.

How to determine the required value

Solr does not provide this information directly. Here’s how we found it:

1. Open the Solr admin UI
2. Navigate to the schema page for the core (/solr/#/{prefix}_master_index/schema)
3. Inspect the page source and search for data-option-array-index
4. Use the highest index value as a reference

If you know a better or simpler method, please share!

SIF integration

To avoid manual changes, we extended the SIF configuration:

• Added a new variable: "Solr.MaxFieldsValue.BigValue": 15000
• Updated the logic in UpdateMaxFieldsValue for relevant indexes (master, web, and inherited ones)

Helpful Links

• Solr 9.8.1 Release
• Sitecore Experience Platform 10.3 Update-3
• Sitecore Experience Platform 10.4 Update-1

Implementing scheduled content publishing in SitecoreAI

After migrating from Sitecore XP to SitecoreAI/XM Cloud, one of my clients was facing the challenge, that the scheduled publishing feature that they previously used is no longer available due to SitecoreAIs restrictions to deploy custom code to the back end.

Sitecore XP as well as SitecoreAI already support restricting content publication to certain time windows but this is only to mark content as being publishable. When the time comes and the item can be published, it still requires someone actively hitting the publish button for that item.

Now I was tasked to implement a scheduled publishing, which should be as close as possible to the old solution to make it as easy as possible for content editors to transition. Requirements were as follows:

• Content authors can schedule content publications by configuring the out of the box publishing restrictions.
• It was not required, that scheduled content publishing is exact to the second and some few minutes delay was acceptable.
• At this point scheduled de-publishing was not a requirement

Solution

The solution is based on two Sitecore Powershell Extensions scripts that run on a schedule. One script fills up a publishing queue with information which item is due at which time. The other script simply runs through the queue and triggers content publishing based on the item configurations in that queue.

Filling up the queue

For the schedule items we create a new template ‘Publishing schedule’ like this:

The script to fill the publishing queue is called “Schedule item publications” and looks like this:

$scheduleFolderPath = '/sitecore/system/settings/Feature/Scheduled Publishing/Publishing schedules/'
$scheduleItemTemplate = '/sitecore/templates/Feature/Scheduled Publisher/Publishing schedule'
$languageVersion = "de-DE"
$debug = $false

function Schedule-Future-Publishing {
    param (
        [string]$itemId
    )
    
    $items = Get-Item -Path "master:" -ID $itemId -Language $languageVersion -Version *
    
    if($debug) {
        if($items.GetType().ToString() -eq 'Sitecore.Data.Items.Item'){
            $path = $items.Paths.FullPath
        } else {
            $path = $items[0].Paths.FullPath
        }
        Write-Host 'Evaluating ' $path
    }

    # Get current UTC time
    $utcNow = [DateTime]::UtcNow.ToString('yyyyMMddTHHmmssZ')
    
    foreach($item in $items) {
        # Here we compare the publishing restrictions with the current date and time
        # If the item has a publishing date, that lies in the future, we create a new item in the publishing queue
        $validFrom = Get-ItemField -IncludeStandardFields -Item $item -ReturnType 'field' -Name "__Valid from"
        
        if($debug) {
            Write-Host 'Comparing: ' $validFrom.Value ' > ' $utcNow ' is: ' ($validFrom.Value -ge $utcNow)
        }
        if($validFrom.Value -ge $utcNow) {
            $targetPath = $scheduleFolderPath + $validFrom + '_' + $item.ID.ToShortID()
            $createdItem = New-Item -Path $targetPath -ItemType $scheduleItemTemplate
            
            $createdItem.Editing.BeginEdit()
            $createdItem["Target Item"] = $item.ID
            $createdItem["Publishing Time"] = $validFrom.Value
            $createdItem["Status"] = 'Pending'
            $createdItem.Editing.EndEdit()
            
            if($debug) {
                Write-Host 'Added ' + $targetPath
            }
        }
    }
}

# Here we can configure all directories, in which we search for scheudled items
$contentDirectories = @(
    '/sitecore/content/MyProject/Home',
    '/sitecore/content/MyProject/Data'
)

# Clear the folder first
# The queue is rebuilt on every run so items, that are already published are cleared from the queue
$childItems = Get-ChildItem -Path $scheduleFolderPath

foreach($childItem in $childItems) {
    Remove-Item -Path $childItem.Paths.FullPath -Force
}

# go through all subitems and their version and check for publishing restrictions
foreach($contentDirectory in $contentDirectories) {
    $contentDirectoryItem = Get-Item -path $contentDirectory -Language $languageVersion

    Schedule-Future-Publishing -itemId $contentDirectoryItem.ID
    
    $contentItems = Get-ChildItem -Path $contentDirectory -Recurse
    
    foreach($contentItem in $contentItems) {
        Schedule-Future-Publishing -itemId $contentItem.ID
    }
}

This script goes through a list of items, that we can configure and their child items and compares the field __Vaild from to the current date and time. If the field value is greater than the current datetime (i.e. the item is scheduled for a future time) we create a new item based on our previously created item an put it into a folder, that serves as our publishing queue.

Via a scheduled task, we configure this script to run once every 24 hours. So, the publishing queue is filled once a day.

Running scheduled publishes

The second script we build will go through the publishing queue and publish items as soon as their target date is reached. Items, that get published also have their Status set from ‘Pending’ to ‘Published’ so they are only considered once for publishing and when the queue is refilled the next time, it will not reappear, because the date lies in the past then.

$scheduleFolderPath = '/sitecore/system/settings/Feature/Scheduled Publishing/Publishing schedules/'
$languageVersion = "de-DE"
$debug = $false

$db = Get-Database "experienceedge"
$lang = [Sitecore.Globalization.Language]::Parse($languageVersion)

$publishingSchedules = Get-ChildItem -Path $scheduleFolderPath

# Get current UTC time
$utcNow = [DateTime]::UtcNow.ToString('yyyyMMddTHHmmssZ')

foreach($publishingSchedule in $publishingSchedules) {
    $validFrom = $publishingSchedule["Publishing Time"]
    
    # only consider items with status Pending and ignore already published items
    if(($validFrom -lt $utcNow) -and $publishingSchedule["Status"] -eq 'Pending') {
        $targetItem = Get-Item $publishingSchedule["Target Item"] -Language $languageVersion
        
        # Smart publish, with related items, no subitems
        [Sitecore.Publishing.PublishManager]::PublishItem($targetItem, $db, $lang, $false, $true, $true)
        
        $publishingSchedule.Editing.BeginEdit()
        $publishingSchedule["Status"] = 'Published'
        $publishingSchedule.Editing.EndEdit()
        
        if($debug) {
            Write-Host 'Published: ' $publishingSchedule.Paths.FullPath
        }
    } else {
        if($debug) {
            Write-Host 'Not due: ' $publishingSchedule.Paths.FullPath
        }
    }
}

Again, we create a scheduled task to run this script once every 10 minutes. As mentioned above it was not necessary to have the item go live at an exact time. This way, we have a maximum delay of 10 minutes to the configured time.

These two scripts fulfilled all requirements as agreed on with the customer and increased the editors’ day-to-day working experience by a far, because they could simply configure publishing restrictions for their items and be assured, that their content goes live without additional steps.

Considerations

This may not be the most elegant solution, and we considered a more efficient solution including webhooks and only triggering the schedule job, when an item is saved, so it is not necessary to evaluate all content repeatedly.

But at this point, we decided to not introduce an additional external service that would be needed to handle the webhook and performance also looked fine with the current amount of content. The script to schedule the item publications ran for ~3 minutes with a volume of 30.000 items, which were evaluated.

Also, I mentioned in the beginning, that de-publishing is not considered at this point, because the customer is not utilizing the “Valid to” configuration now. The script could be easily extended to cover that requirement as well, but for the sake of simplicity I left it out in this blog post.

I hope this will serve helpful to someone else looking for this common requirement and happy to hear about your solutions, how you solved this problem.

Head image was created via Copilot

Finally, I reached my Sitecore localhost test URL in the browser, expecting the site to appear. Unfortunately, it didn’t work.

I recalled that the site was heavily dependent on Solr indexes—particularly two custom indexes in addition to the sitecore_master_index and sitecore_web_index. So I began investigating the indexes by:

• Repopulating the schema to Solr (this worked well)
• Starting the index rebuilds (surprisingly slow)

I remembered that the solution’s indexing had been extended significantly with various customizations. I wasn’t sure if I was misremembering the indexing performance or if it had always been this slow.

I started disabling customizations such as computed fields and custom field type registrations. The result: no improvement. I also debugged and investigated further but didn’t uncover anything new.

Why were Solr indexes—configured identically and running on the same Solr instance—indexing at different speeds?

After mentally reviewing all the involved resources and categorizing them as:

• Exactly the same
• Theoretically the same with minor differences (e.g., different names)
• Truly different

I concluded that I needed to check the databases. This was especially relevant because the two problematic indexes were both tied to the web database.

As a Sitecore developer, you naturally consider the differences between the master and web databases from a content perspective. Typically, the web database contains only published data, making it smaller and faster to index.

So I checked something I rarely examine as a Sitecore engineer: the SQL database table indexes.

When I looked into the master database’s Items and Fields tables, the index sizes appeared normal. However, the corresponding tables in the web database were empty or nearly empty—clearly incorrect.

**I proceeded to rebuild the SQL table indexes: Right-click → Indexes → Right-click “Rebuild All”**

Seconds later, the index sizes looked promising.

A Sitecore index rebuild confirmed that the indexing process was now hundreds of times faster. Instead of the status counter increasing one by one every second, it resumed its natural behavior—jumping in steps of 100+.

Although I’m not sure how the database indexes were lost (perhaps due to a restore or other process), I’m glad I identified the issue in an area I usually don’t need to worry about as a Sitecore engineer.

So, if you encounter similar behavior, be sure to check your SQL table indexes!

On April 3-4, the 10th Sitecore User Group Conference took place in Antwerp, Belgium. For one and a half days, community members from all over the world could meet and exchange ideas at the incredible venue “A Room with a Zoo”.

I had already attended a Symposium in the past as well as multiple Sitecore User Group Germany meetups. But this was the first time I could visit SUGCON, and I was excited to learn about the latest product developments, get inspiration from other Sitecore developers, and meet new and old friends.

As you would expect, the dominating topics were AI and especially Sitecore Stream, and XM Cloud. But I enjoyed seeing innovative solutions from other community members and hearing about new and planned features from the Sitecore product teams.

In this post, I will share a brief recap of my highlight sessions and my personal opinion on some of these topics.

Day 1

Since I was traveling that day, I could not attend the two workshops on migrating XM/XP to XM Cloud best practices and Content Hub optimizations. The event started with the opening keynote.

Keynote: Powering the Future of Sitecore

The event was kicked off by Sitecore CEO Dave O’Flanagan. He shared with us the future roadmap of Sitecore and the key role that AI and Sitecore Stream will play in it, even for the “old” XM/XP solutions that Sitecore is still committed to further maintain and innovate, and which can also utilize Sitecore Stream.

We got a glimpse of the new XM Cloud App Marketplace, which will allow developers to deploy custom plugins to XM Cloud and share them with others via the Marketplace.

In a short demo, we also saw the “CI Hub” connector, which can be used to easily integrate Content Hub with your typical Office or Creative Software like Photoshop or PowerPoint.

Events, Webhooks, & the Authoring API

Jason Wilkerson demonstrated in this session how webhooks and events can be utilized to run custom logic on items. He showcased a custom-built app that can create new content within XM Cloud only by API and without opening the Content Editor once, which could, in a further step, also be used for automation.

It was good to see how customizations in the SaaS world can still work and what tools developers can use, especially when planning to move from XM/XP to XM Cloud, where we see a huge shift in how backend logic can be built.

Unlocking the Power of Sitecore Search

Jeroen Speldekamp brought us three hands-on proof of concepts:

1. How to use Geo data for a distance-aware search
2. How to use marketing campaigns to trigger certain rules
3. How to easily generate a simple chatbot/FAQs by generating questions and answers with Sitecore Stream based on data that was indexed from a website

Here I really enjoyed the innovative way Sitecore Stream was used to speed up a tedious process like generating an FAQ and seeing the power of Sitecore Search in action.

Day 2

Day 2 started early after a great community dinner the evening before, where I had the chance to meet and exchange with others, digest all the information from that day, and enjoy great food.

The first session of the day was an update on Sitecore Stream in XM and XP.

Sitecore Stream in DXP

Vignesh Vishwanath demonstrated how the Sitecore Stream features will be integrated into XM and XP and how they can be installed. My key takeaways:

• Minimum version is 10.2
• A Sitecore Cloud Portal account is required
• Stream can be downloaded as an installable module
• It is available as a free tier or paid subscription
• It’s a bit tricky to find the module, so best you contact your respective partner manager

Step-by-Step Optimization for Next.js and Sitecore JSS

This session by Alex Hawley, I did not attend, but it was highly praised by many people I talked to. I can recommend this blog post, though, that covers the same topic: How to Optimize Next.js + Sitecore JSS.

He also holds this talk on other platforms, so keep an eye on the Slack channels if you have also missed his talk at SUGCON.

Elevating Developer Experience: Modernizing the JSS SDK and Starter Kits for XM Cloud

Liz Nelson and Christian Hahn presented the new “Content SDK”, which is at the moment still in beta version but is expected to go to first release within the next few months.

The Content SDK is a reduced version of the JSS SDK. These reductions were achieved by removing all code that is related solely to XM and XP (e.g., the Experience Editor). So the new Content SDK will only work for XM Cloud and from now on, both SDKs will be developed independently from each other.

You can already check out the Content SDK here. If you are starting a new project now, the recommendation from Sitecore is to already start using the Content SDK as its first stable release is expected very soon. If you plan to migrate your JSS SDK app to Cloud SDK, you should wait for the official release.

The same has been done for the XM Cloud starter kits, which received a major rebrush to make it easier to understand and to create as little boilerplate code as possible.

Accelerating Success

Katharina Luger gave a nice lightning talk introducing the Sitecore Acceleration campaign with the most interesting part being the cookbook: Sitecore Accelerate Cookbook.

This is a collection of best practices where developers and consultants can find recommended solutions or approaches based on certain scenarios.

Currently, they cover XM Cloud and Content Hub, but the rest of the Cloud portfolio as well as XM and XP is already planned. So it is worth revisiting the page from time to time and checking for updates.

Sitecore’s Marketplace Roadmap Review & Developer Program

Krassi Eneva and Justin Vogt gave us a deeper look into the new XM Cloud App Marketplace.

The Marketplace is still in a closed testing phase and is planned to be published later this year. What we already know:

1. Apps can have three scopes:
   1. Public: Available to everyone on the Marketplace (apps can be made free, paid, or freemium)
   2. Organization: Apps are available across multiple projects in the same organization (e.g., if you want to reuse a certain feature across multiple customer projects)
   3. Private: Can only be used on one certain project (makes sense if the app covers very specific business logic)
2. Apps will be reviewed by Sitecore including the design
   1. It is not necessary but recommended to use Sitecores Blok Design System
3. The Marketplace SDK is already available
4. Apps can extend certain functionalities like Pages or create new Dashboards

I’m looking forward to this new platform and what exciting ideas the community will come up with to extend Sitecore functionalities.

A Walk-through of XM Cloud Content

In the last session, Alistair Deneys gave a very hands-on demonstration of Sitecore’s new CMS “XM Cloud Content”. This will be a truly headless lightweight CMS with a couple of nice extra features.

In his demo, Alistair created a simple blog post including referenced authors by only using XM Cloud Content’s API. The demo included the whole process from defining the content structure to eventually publishing and requesting the created content.

He also highlighted the simplified architecture, that there will not be a separate WEB database, and publishing an item will simply change the entry’s publishing field. This has the nice effect that scheduled publications are easily possible out of the box.

Alternatively to the API, XM Cloud Content has an intuitive user interface as well, where users can define new content templates, create new content, and maintain it.

Right now, this new product is still under development and I am already looking forward to getting some hands-on experience with XM Cloud Content.

Closing Words

My first SUGCON ended with the closing ceremony and I left with many new impressions and ideas. I cannot wait to apply my learnings to real projects and I will be looking forward to the next SUGCON event.

Big thanks to all organizers, speakers, and all the people involved in making this great community event possible.

Introduction

Sitecore Connect for Content Hub (SCCH) is a bridge between Sitecore Experience Platform and Sitecore Content Hub to synchronize data between the two platforms. It allows editors and marketers to work seamlessly with content created in Sitecore Content Hub. This integration helps maintain consistency and efficiency across different platforms.

With SCCH version 5.2 Sitecore introduced many new features to the connector so we planned to do an upgrade of SCCH from version 5.0 to 5.2. Throughout this process I faced multiple challenges, which rendered this supposedly very small ticket to be more complex than expected.

The conditions I worked with were as follows:

• Sitecore version 10.2.1.
• Locally running on docker.
• UAT and PROD running on Kubernetes.
• We took the solution over from another agency and were not involved in the installation of the SCCH in the first place.

The goal was clear and the road ahead was well documented so: “ready, set, go!”

Initial challenges with the mssql-upgrade step

While going through the documentation, we first stumbled upon the mssql-upgrade step because we could not find any hint in the solution, that the already existing items were created utilizing an mssql-init image.

So, we asked Sitecore Support for clarification and got the response, that the mssql-upgrade image is not necessary when you have already version 5.0 or higher installed. The image is only used to clean old items from installations of versions lower than 5.0.

Items as resources

From version 5.0 onwards SCCH is utilizing “Items as resources”. This approach was introduced with Sitecore 10 and allows to store items not in the database but in the file system instead. So, the needed items for the upgraded SCCH should be present as files in the image, that we import to our CM image. During startup Sitecore loads the synchronized items from the file into the Content Editor.

To verify, that it worked we simply look for the following two folders in the item tree:

• /sitecore/system/Modules/CMP
• /sitecore/system/Modules/DAM

These items belong to the SCCH and are included in the docker image as .dat files.

Resource merger issues

“So I can simply update the CM docker image according to this documentation and DLLs, configs and also the items will be deployed to my CM container”, I thought.

However, the items were not there and with the benefit of hindsight I can say that next I went down a rabbit hole into the completely wrong direction.

I start to further investigate on “Items as resources.”

First, I confirm that the files are properly copied to the CM container, no issue here.

But when I check the logs, I find entries from the “Resource merger”, where I see, that it works generally, only the files from “sitecore modules” are ignored:

2788 21:26:40 INFO  Resource merger: file C:\INETPUB\WWWROOT\SITECORE MODULES\ITEMS\CMP\MASTER\ITEMS.MASTER.CMP.DAT, updated item definitions count = 0.
2788 21:26:40 INFO  Resource merger: file C:\INETPUB\WWWROOT\SITECORE MODULES\ITEMS\CMP\MASTER\ITEMS.MASTER.CMP.DAT, new item definitions count = 65.
2788 21:26:40 INFO  Resource merger: file C:\INETPUB\WWWROOT\SITECORE MODULES\ITEMS\CMP\MASTER\ITEMS.MASTER.CMP.DAT, updated shared definitions count = 0.
2788 21:26:40 INFO  Resource merger: file C:\INETPUB\WWWROOT\SITECORE MODULES\ITEMS\CMP\MASTER\ITEMS.MASTER.CMP.DAT, new shared definitions count = 65.

While looking for the cause of this issue I learned about Protobuf, which is the serializer that is used for the items, that are stored on disk and about the Sitecore Protobuf Browser – a nice tool to compare multiple files. I used this to compare the serialized items of 5.0 and 5.2 to make sure, there are no incompatible items included, without success though.

So next I check for any misconfigurations and look at that, these filePaths look suspicious:

<protobufItems type="Sitecore.Data.DataProviders.ReadOnly.Protobuf.ProtobufDataProvider, Sitecore.Kernel" patch:source="Customer.Project.ChubConnector.config">
<filePaths hint="list" patch:source="Customer.Project.ChubConnector.config">
<filePath>/App_Data/items/$(id)</filePath>
<modulesFilePath>/sitecore modules/items/$(id)</modulesFilePath>
</filePaths>
</protobufItems>

The way these paths are configured, they will not pick up the files from the CMP and DAM modules, so I add these two lines via patch file to the databases:

<cmpModulesFilePath>/sitecore modules/items/cmp/$(id)</mpModulesFilePath>
<damModulesFilePath>/sitecore modules/items/dam/$(id)</damModulesFilePath>

I rebuilt the image and now the items were there. At this point I was sure, that I found a bug in the chub-assets image (this will turn out to be false). I checked in my changes, deployed to UAT, tested the Connector … and it did not work. The items were there, but when I tried to pick an asset from the DAM, the dialogue stayed blank.

Missing configurations

I debugged the dialogue and quickly found out, that an api request to /sitecore/api/dam/MContent/GetAuthenticationDetails is returning a 404.

This api endpoint is defined in a DLL from the SCCH module and I could also confirm that this DLL was properly deployed to the CM instance.

Now do you remember, how I was chasing that white rabbit named “Items as resources?” Because next I did something, I should have done in the first place. I checked the showconfig.aspx, if the module configs were applied and if the processor that registers the api route is added. At this point I realized that none of the configurations were applied to Sitecore. I checked again the config files inside the module image and learned, that they require a certain setting:

<sitecore damEnabled:require="yes">…</sitecore>

This turns out to be a change introduced with version 5.1 and you can also find the documentation to Enable CMP or DAM here.

Implementing the final fixes

But I had to clear out one last hurdle, because the config change just would not apply, no matter what I tried and eventually I found a mistake in our dockerfile, where the transformations from the SCCH module are done after our custom transformations and the module contains a transformation itself, that explicitly sets the values to false.

This must run last.

After reordering the transformation steps, the settings finally changed to “yes” and I could see, that all configs were correctly applied – including the supposedly missing resource paths, as I described earlier, which I thought was a bug and all is fine and working.

After hours of work, which could have been an hour I could finally declare sweet victory.

Conclusion

What do I take from this endeavor?

1. When in doubt, check the showconfig.aspx first.
2. I learned about items as resources.
3. Do not forget release notes when doing an upgrade, e.g. Release Notes for SCCH 5.1.0

Even with all the challenges I faced I am still happy with the result, as I was able to learn a few new things but would be just as happy, if this post saves someone a couple of head scratches and hours.

Head image by Interactive Sports on Unsplash

Introduction

With a Kubernetes solution such as AKS, it is easier to scale the application according to your needs and simpler to deploy. However, troubleshooting is more difficult and requires different tools than with an app service solution.

Tooling

OpenLens

OpenLens is a GUI tool to manage Kubernetes clusters, without the need of extensive command line usage. It can be downloaded here.

Pod Menu Extension

With version 6.3.0, the Node / Pod Menu with the useful functionalities attach, shell and logs were removed from OpenLens.

To bring it back, you can add the POD Menu Extension from this repository.

Alternatives

Currently OpenLens is the tool I use, but since the project is no longer being maintained, there are alternative open source tools that I may use in the future. They are very similar, free, open source and actively in development, here are some examples:

• K9s
• Jet Pilot
• Seabird

Connection to Azure

To connect an AKS Cluster from your local machine, first close your OpenLens instance, go to the Azure Portal, find your AKS Cluster (1), go to Overview (2) and press Connect (3).

On the right side of the browser, a menu will open. Select Azure CLI and follow the instruction.

Config file

Adding the cluster via Azure CLI will edit your Kubernetes config file on your machine. Usually, it’s located on C:\Users\USERNAME.kube

You may need to add the Kubernetes folder to OpenLens via menu, File, Preferences:

Go to Kubernetes (1), press Sync folder (2) and add the folder where the Kubeconfig file is stored C:\Users\USERNAME.kube

Clusters in OpenLens

After adding the clusters, in the Catalog (1) select Clusters (2) and you will see all the added clusters (3) in the overview.

Namespace filter

When you open the Pods menu (1), and see only one pod (2), it’s possible that the selected namespace (3) is not the one you want. You can op the namespace dropdown menu (4) and select the one you want.

Basic operations

View and download logs

To view the live logs of a Pod, go to Workloads (1), then Pods (2), select the Pod (3), press Pod logs (4) from the pod menu extension, select the container (5) and the logs will shown in the terminal below (6).

To download all logs, click on the Download button (1) and choose between All logs (2).

Pod Shell

You can use the pod shell to use shell commands for example on the CM. Go to Workloads (1), then Pods (2), select the Pod (3) and press Pod Shell (4). The Pod Shell will open on the bottom (5) where you can navigate to a folder, list, read, or update files.

Restart a deployment

1. Go to Workloads
2. Deployments
3. Select the deployment you want to restart
4. Press the restart button and confirm

The Terminal

There is a Terminal (1) in OpenLens, with that you can use directly kubectl commands without any additional installation.

Copy files from a container to your computer

With the terminal, you can copy for example a dll to your local machine by using following command:

kubectl cp -n sitecore sitecore-cd-abcd123456-foo12:\inetpub\wwwroot\bin\website.dll .\localwebsite.dll

The command is composed as follows:

kubectl cp -n NAMESPACE sitecore-cd-YOUR-POD:PATH_TO_REMOTE.DLL .\LOCAL_PATH.DLL

Copy files from your computer to a container

Copying a local file to the remote container is based on the same principle:

kubectl cp .\localwebsite.dll -n sitecore sitecore-cd-abcd123456-foo12:\inetpub\wwwroot\bin\website.dll

Conclusion

Troubleshooting an AKS solution can be a challenge, but with the right tools it can be easily managed. On the other hand, many things, such as deploying individual services without downtime, are much easier. We have been using OpenLens for a long time, it is a pity that the open source development has been discontinued, but there are many alternatives.

Recently on our live website, indexes stopped working while showing data from a particular page type. Also on these pages, most components were missing. Everything was working fine on the master database. In the logs, we found the following error:

Message: Could not map index document field to property "Paths" on type App.Foundation.Search.SearchResultItem : Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Actual value: [orphan]

Also, when we visited those pages on the web database and opened presentation details, it was not possible to check the datasource, because the browse button was throwing an error if the component datasource was coming from the local datasource. In the logs, we found the following error:

Exception: System.NullReferenceException
Message: Object reference not set to an instance of an object.
Source: Sitecore.XA.Foundation.LocalDatasources
   at Sitecore.XA.Foundation.LocalDatasources.RenderingDatasources.DatasourceSettingsProvider.GetSettingsItem(Item contextItem, ID renderingId)
   at Sitecore.XA.Foundation.LocalDatasources.RenderingDatasources.DatasourceSettingsProvider.HasSettings(Item contextItem, ID renderingId)
   at Sitecore.XA.Foundation.LocalDatasources.Pipelines.GetRenderingDatasource.AddAdditionalTemplates.Process(GetRenderingDatasourceArgs args)
   at (Object , Object )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain, Boolean failIfNotExists)
   at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain)
   at Sitecore.XA.Foundation.LocalDatasources.CustomFields.FieldTypesEx.BucketInternalLink.ShowDialog(ClientPipelineArgs args)

So we had 2 different problems that might be connected.

With these clues in hand, we checked indexes for these page types. Then, found out that there were many cases with [orphan] assigned to the _path field:

We tried rebuilding databases but it didn’t help and [orphan]s stayed. 

Then we tried database cleanup from sitecore/admin/dbcleanup.aspx:

and rebuild indexes again. All orphans got cleared from indexes.

Once we checked the error we got from local datasources, we also saw that the error was gone.

Indexes worked again, pages were showing components after clearing the caches.

Introduction

In the world of digital marketing, email campaigns are a crucial tool for engaging with our audience, driving conversions, and building brand loyalty. However, even the most meticulously planned campaigns can face unexpected challenges. Recently, we encountered a significant disruption when our system crashed mid-dispatch, causing our email campaigns to get stuck. Here’s a look at what happened, how we responded, and the lessons we learned from the experience.

The Incident: When Things Went Off Track

The campaigns were designed to reach thousands of subscribers with personalized content that would resonate with their interests.

But then, the unexpected happened. Just as the second campaign of three was rolling out, our CM server crashed due to another issue.

The result? Hundreds of emails were stuck in limbo, neither reaching the inboxes nor bouncing back as undeliverable.

Recovery: Getting Back on Track

Once the system was back online, we had to decide how to proceed with the campaign.

Our options included resending the emails that were stuck or pausing the campaign altogether to avoid overwhelming our subscribers. After careful consideration, we chose to stagger the dispatch of the remaining emails. This allowed us to complete the campaign without bombarding recipients or risking further technical issues. We also took this opportunity to recheck the content and timing, ensuring that the messages were still relevant and effective.

Solution

Since the campaign with the status “Sending” stopped with a progress of 40%, we wanted to be sure and reach out to the Sitecore Support team to find the best technical solution.

In this case, we need to manually change the states. Pausing and resuming the campaign was not possible in our case. Clicking the Button in the Delivery tab of the campaign did not change anything.

So manually modifying the related message status in the EXM.Master DB helps.

Here is the SQL script we used:

USE [Sitecore.Exm.master]
GO

UPDATE [dbo].[Campaigns]
SET [Status] = 'Paused'
WHERE MessageID = 'Your campaign id'
GO

By setting the status to Paused we were able to resume the campaing by clicking Resume in the Delivery tab of the campaign.

You need also to find the campaign in the Content Editor by searching with the campaign ID, unprotect the item, and set the status again there to Draft to be able to send the Mail through the UI. That worked out.

After the successful send-out of this campaign, the last one with the Status Queuing remains in that state. Sitecore does not get the information to continue with the next campaign. That needs to be considered.

So we decided here to set the state to Draft by utilizing the SQL statement from above. Again, you need also to find the campaign in the content editor by searching with the campaign ID, unprotect the item, and set the status there to Draft to be able to send the Mail through the UI.

Image from Mohamed Hassan on Pixabay

Based on the previous blog post about (extenting Sitecore’s general link), you may also want to enhance the content editing experience for your editors by extending the rich text editor with your newly created link.

In this tutorial, I’ll guide you through the steps to create a custom dialog for Sitecore’s rich text editor. To achieve this, follow the specified steps:

1. Create your custom DialogForm class

The first thing you need to do is create your custom DialogForm. It should derive from DialogForm, and you’ll need to override OnCancel and OnOK methods.

For example: Extending General Link Fields with Tracking Data

As in our example, you want to enhance the general link fields in your custom dialog by adding tracking data, specifically the fields EventCategory, EventAction, and EventLabel. You can follow these steps:

• Create your custom DialogForm class, inheriting from the base DialogForm.
• Override the OnCancel and OnOK methods to handle the dialog behavior.
• In the OnOK method, retrieve the values from your custom fields (e.g., EventCategory, EventAction, and EventLabel).
• Append these values to the result or perform any other necessary actions based on the user’s input.

using Sitecore;
using Sitecore.Diagnostics;
using Sitecore.Shell.Applications.ContentEditor;
using Sitecore.Text;

using Sitecore;
using Sitecore.Diagnostics;
using Sitecore.Web.UI.HtmlControls;
using Sitecore.Web.UI.Pages;
using Sitecore.Web.UI.Sheer;

using System;
using System.Diagnostics.CodeAnalysis;
using System.Text;

namespace Your.own.namespace
{
	[ExcludeFromCodeCoverage]
	public class InsertLinkWithTracking : DialogForm
	{
		protected Edit URL;
		protected Combobox Target;
		protected Edit Class;
		protected Edit Title;
		protected Edit Querystring;
		protected Edit EventCategory;
		protected Edit EventAction;
		protected Edit EventLabel;

		protected override void OnCancel(object sender, EventArgs args)
		{
			Assert.ArgumentNotNull(sender, "sender");
			Assert.ArgumentNotNull(args, "args");
			if (this.Mode == "webedit")
			{
				base.OnCancel(sender, args);
			}
			else
			{
				SheerResponse.Eval("scCancel()");
			}
		}

		protected override void OnOK(object sender, EventArgs args)
		{
			Assert.ArgumentNotNull(sender, "sender");
			Assert.ArgumentNotNull(args, "args");
			if (string.IsNullOrWhiteSpace(URL.Value))
			{
				SheerResponse.Alert("Bitte geben Sie die URL ein.", Array.Empty<string>());
			}

			if (this.Mode == "webedit")
			{
				base.OnOK(sender, args);
			}
			else
			{
				var result = new StringBuilder($"href=\"{URL.Value}");
				if (!string.IsNullOrWhiteSpace(Querystring.Value))
				{
					if (Querystring.Value.StartsWith("?"))
					{
						result.Append(Querystring.Value);
					}
					else
					{
						result.Append($"?{Querystring.Value}");
					}
				}
				result.Append('"');
				if (!string.IsNullOrWhiteSpace(Target.Value))
				{
					switch (Target.Value)
					{
						case "New":
							result.Append(" target=\"_blank\"");
							break;
					}
				}
				if (!string.IsNullOrWhiteSpace(Class.Value))
				{
					result.Append($" class=\"{Class.Value}\"");
				}
				if (!string.IsNullOrWhiteSpace(Title.Value))
				{
					result.Append($" title=\"{Title.Value}\"");
				}

                // Custom fields for tracking link
				if (!string.IsNullOrWhiteSpace(EventCategory.Value)
					&& !string.IsNullOrWhiteSpace(EventAction.Value)
					&& !string.IsNullOrWhiteSpace(EventLabel.Value))
				{
					result.Append($" data-clickevent=\\'{ {\"eventCategory\": \"{EventCategory.Value}\", \"eventAction\": \"{EventAction.Value}\", \"eventLabel\": \"{EventLabel.Value}\"} }\\'");
				}

				SheerResponse.Eval($"scClose('{result}')");
			}
		}

		protected string Mode
		{
			get
			{
				string str = StringUtil.GetString(base.ServerProperties["Mode"]);
				if (!string.IsNullOrEmpty(str))
				{
					return str;
				}
				return "shell";
			}
			set
			{
				Assert.ArgumentNotNull(value, "value");
				base.ServerProperties["Mode"] = value;
			}
		}
	}
}

Remark:

• Each line of code except the custom field part originates from the decompiled source of the Sitecore’s code.
• It is recommended to place the file in “…\sitecore\shell\Controls\Rich Text Editor...” where all the general controls for the rich text editor of Sitecore are placed.

2. Create the XML for your custom dialog

The next step is to create the visual presentation of the dialog. Therefore, you have to create an XML file which contains the control definition for the dialog. In the example you can find the tree new fields (EventCategory, EventAction and EventLabel) for our custom tracking link. Additionally, the CodeBeside links to our previous created class.

<?xml version="1.0" encoding="utf-8" ?>
<control xmlns:def="Definition" xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense">
	<RichText.InsertLinkWithTracking>
		<FormDialog Icon="office/32x32/edit_in_workflow.png"
					Header="Link mit Tracking einfügen"
					Text=""
					OKButton="Link">
			<script Type="text/javascript" Language="javascript" Src="/sitecore/shell/Controls/Rich Text Editor/InsertLinkCommon.js">.</script>
			<CodeBeside Type="Your.own.namespace.InsertLinkWithTracking, YourSolution"/>

			<GridPanel Class="scFormTable" Width="100%" CellPadding="2" Columns="2" GridPanel.VAlign="top" GridPanel.Style="padding-left: 20px">
				<Literal Text="URL:" GridPanel.NoWrap="true"/>
				<Edit ID="URL"/>

				<Label for="Target" GridPanel.NoWrap="true">
					<Literal Text="Target Window:"/>
				</Label>
				<Combobox ID="Target" Width="100%">
					<ListItem Value="Self" Header="Active browser"/>
					<ListItem Value="New" Header="New browser"/>
				</Combobox>

				<Literal Text="Style Class:" GridPanel.NoWrap="true"/>
				<Edit ID="Class"/>

				<Literal Text="Alternate Text:" GridPanel.NoWrap="true"/>
				<Edit ID="Title"/>

				<Literal Text="Query String:" GridPanel.NoWrap="true"/>
				<Edit ID="Querystring"/>

				<Literal Text="Tracking Informationen:" GridPanel.Colspan="2"/>

				<Literal Text="Event Category:" GridPanel.NoWrap="true"/>
				<Edit ID="EventCategory"/>

				<Literal Text="Event Action:" GridPanel.NoWrap="true"/>
				<Edit ID="EventAction"/>

				<Literal Text="Event Label:" GridPanel.NoWrap="true"/>
				<Edit ID="EventLabel"/>
			</GridPanel>
		</FormDialog>
	</RichText.InsertLinkWithTracking>
</control>

3. Add your custom control to the rich text commands

In the third step, you need to extend the out-of-the-box JavaScript file that calls your dialog. Therefore, you can copy the default “RichText Commands.js”file from Sitecore and extend it with your newly created control. It is recommended to also place the file in “…\sitecore\shell\Controls\Rich Text Editor...”.

For our example, we added the following code snippet:

// Add the action from the HTML Edit Button Item to CommandList.
Telerik.Web.UI.Editor.CommandList["InsertLinkWithTracking"] = function (commandName, editor, args) {
	var d = Telerik.Web.UI.Editor.CommandList._getLinkArgument(editor);
	Telerik.Web.UI.Editor.CommandList._getDialogArguments(d, "A", editor, "DocumentManager");
	scEditor = editor;
	// Call the dialog box.
	editor.showExternalDialog(
		"/sitecore/shell/default.aspx?xmlcontrol=RichText.InsertLinkWithTracking&la=" + scLanguage,
		null, //argument
		500, //Width
		550, //Height
		scInsertLinkWithTrackingCallback, //callback
		null, // callback args
		"InsertLinkWithTracking",
		true, //modal
		Telerik.Web.UI.WindowBehaviors.Close, // behaviors
		false, //showStatusBar
		false //showTitleBar
	);
};

// The function is called when the user closes the dialog.
function scInsertLinkWithTrackingCallback(sender, returnValue) {

	if (!returnValue) {
		return;
	}
	var selectedHtml = scEditor.getSelectionHtml();
	if (typeof selectedHtml === "undefined") {
		scEditor.pasteHtml("", "DocumentManager");
	} else {
		scEditor.pasteHtml("<a " + returnValue.text + ">" + selectedHtml + "</a>", "DocumentManager");
	}
};

4. Add a custom button for the rich text editor

Last but not least a button needs to be placed on the rich text so that the dialog can be triggered.

Therefore follow these steps:

• Switch the database in Sitecore to the core database and navigate to the following path: “/sitecore/system/Settings/Html Editor Profiles”. Here, you’ll find various rich text editor profiles that you can customize.
• Select the profile you want to extend. For example, let’s say you choose the “Rich Text Full” profile.
• Add a Html Editor Button to the toolbar. In our example we added the button to “Toolbar 1”.
• Customize the button’s properties. In the Data section add your Click-Event to the field Click. In our example InsertLinkWithTracking.
• To make your button easily identifiable, add a meaningful icon.

5. Test your implementation

Now everything is implemented and you can test your custom dialog in the rich text editor by clicking the buton in the rich text toolbar.

If all fields are filled out, the output for our link with tracking will be as follows:

<a href="/test" title="Link with tracking" data-clickevent="{'eventCategory': 'Test Category', 'eventAction': 'Test Action', 'eventLabel': 'Test Label'}">Custom link with tracking</a>

Remark: If the dialog shows an error message or doesn’t load correctly, clear your cache and reload the page.

Conclusion

Let’s wrap it up by summarizing the steps to extend the default rich text editor with your custom button:

• Create your custom DialogForm.cs file
• Create the control for your custom dialog
• Extend the JavaScript file with your control
• Add a “Html Editor Button” to the toolbar in the core database

As you can see, customizing the rich text editor with your own dialog is relatively straightforward and for your content editor, it is an important step to enhance the content editing experience.