🚀 Sitecore 10.4 SXA Upgrade: Language Embedding Issue & Temporary Workaround

Hi everyone! 👋

We recently upgraded our Sitecore platform from version 10.1 to 10.4, along with the SXA module. While the overall upgrade process was largely seamless — thanks to Sitecore’s detailed documentation — we did run into a few unexpected challenges that I believe are worth highlighting. This post is especially for those planning a similar upgrade journey.

If you’re just starting out, I recommend reviewing my earlier blogs where I outline key upgrade steps and best practices. For now, let’s focus on one specific post-upgrade issue we encountered: language embedding in URLs not functioning as expected.

🧩 The Issue: Language Embedding Not Working Properly

Our SXA-based websites rely on language embedding to ensure that URLs include the language code, such as:

https://hostname/en-CA/medical

However, post-upgrade we observed two key problems:

• The language prefix was not applied at the hostname root.
• While language switching on the website technically worked, the URL did not reflect the language change, leading to user confusion.

Initially, we suspected a bug in our custom implementation. But after deep investigation and coordination with Sitecore Support, it was confirmed to be a product-level issue. (Reference: Case #CS0585903, awaiting official confirmation.)

The root cause was traced to the SwitchableLinkProvider, which wasn’t honoring the Language Embedding checkbox in the SXA settings. Sitecore acknowledged the issue and has scheduled a fix under reference SXA-8360.

🛠 Temporary Fix: Custom Link Provider Implementation

While waiting for the official hotfix, we needed an immediate workaround due to our reliance on this feature across multiple sites.

Here’s the temporary solution we implemented:

• We configured a custom link provider to replace the default SwitchableLinkProvider.
• A simple patch config was added.
• In the SXA Site Grouping settings, we explicitly set the Link Provider name to use our custom provider.

This resolved the language embedding issue across all URLs.

Patch Example:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
   <sitecore>
      <linkManager defaultProvider="switchableLinkProvider" >
         <providers>
            <add name="CustomLinkProvider" type="Sitecore.XA.Foundation.Multisite.LinkManagers.LocalizableLinkProvider, Sitecore.XA.Foundation.Multisite" lowercaseUrls="true" languageEmbedding="always" addAspxExtension="false" />
         </providers>
      </linkManager>
   </sitecore>
</configuration>

⚠️ Note: This is a temporary workaround. We’re still awaiting the official Sitecore patch and will share updates once it’s available.

💬 Final Thoughts

Upgrading to newer Sitecore versions — especially when SXA is involved — can surface subtle yet impactful issues. The important takeaway:

• Stay proactive,
• Don’t hesitate to involve Sitecore Support, and
• Be open to temporary creative workarounds when business continuity is on the line.

💡 “There are many solutions to a problem. The challenge is identifying the right one at the right time.”

Happy coding! 🔧
 Have you encountered similar issues during your upgrade? I’d love to hear your experiences and solutions in the comments.

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.

🚀 Streamlining Sitecore Maintenance Post-Upgrade: How PowerShell Helped Us Fix Missing Templates and Flashes Items

Hi Sitecore folks! 👋

Upgrading Sitecore is always an exciting step forward — more features, improved performance, and enhanced stability. But let’s be honest: it’s not always smooth sailing.

We recently upgraded from Sitecore 10.1 to 10.4, and while most things worked seamlessly, we hit a snag that many of you might also face post-upgrade — orphaned or missing templates, especially related to SXA Flash items.

In this blog, I’ll walk you through:

 ✅ What went wrong
 ✅ Why it mattered
 ✅ How we solved it using PowerShell (our superhero 🦸‍♂️)
 ✅ And how you can do it too

Whether you’re maintaining a single Sitecore instance or overseeing 160+ SXA-based websites like we are — this one’s for you.

🧨 The Issue: Missing Templates for Flash Items

After the upgrade, we noticed something odd in our SXA environments. In the Data folder, several “Flashes” items were still visible — but something wasn’t right:

• We couldn’t interact with them.
• Their templates were missing.
• Deletion through the Content Editor? Not possible.

That’s when we turned to the old-school trick of visiting /sitecore/admin/dbbrowser.aspx, where we could manually select and delete these items. But here’s the thing—with 160+ websites across Dev, UAT, and Prod, manual cleanup just wasn’t an option.

😫 Why Manual Fixes Just Don’t Scale

When you’re dealing with tens or hundreds of websites, manual steps become a maintenance nightmare. What if you miss one? What if someone deletes the wrong thing?

We needed:

• 💡 A repeatable, automated process
• ⚡ A fast solution
• 🔄 The ability to run across multiple environments without human error

And that’s where PowerShell stepped in and saved the day.

💻 PowerShell to the Rescue

One of the most powerful tools in the Sitecore ecosystem is PowerShell Extensions (SPE). If you’re not using it yet — trust me, you’re missing out.

We wrote two scripts:

1. ✅ One to identify Flash items with missing templates
2. ❌ Another to delete them safely

🔍 Step 1: Identify Orphaned Flash Items

Here’s a sample PowerShell script that recursively searches for Flash items with missing templates:

# Define the template Name for the Settings item
$dataFolderTemplate = "DataFolder"

# List to hold matching flashes items
$matchingFlashes = @()

# Fast query to get all Settings items under /sitecore/content with the specified template ID
$dataItems = Get-Item -Path master: -Query "fast:/sitecore/content//*[@@templatename='$dataFolderTemplate']"

foreach ($dataItem in $dataItems) {
    
    # Check if the Settings item has a flashes item under it
    $flashPath = "$($dataItem.Paths.FullPath)/Flashes"
    $flashItem = Get-Item -Path $flashPath -ErrorAction SilentlyContinue

    # If flashes item exists and matches the target template ID
    if ($flashItem -ne $null) {
        #$flashItem | Set-ItemTemplate -Template $targetTemplateId
        #Publish-Item -Item $flashItem -Target "web" -Recurse
        
        $matchingFlashes += $flashItem
        #$flashItem | Remove-Item
        #Write-Host "  Found flashes: $($flashItem.Paths.FullPath)"
    }
    else{
        Write-Host " Not Found flashes: $($dataItem.Paths.FullPath)"
    }
}

# Output matched flashes items
#$matchingFlashes | Select-Object Name, TemplateName, @{Name="Path";Expression={$_.Paths.FullPath}}
$matchingFlashes | Show-ListView -Property Name, TemplateName, @{Name="Path";Expression={$_.Paths.FullPath}} -Title "Flash under Home"
# Show total count of matching $matchingFlashescts items
Write-Host ""
Write-Host "Total matching flashes items: $($matchingFlashes.Count)" -ForegroundColor Green

📌 This script outputs a clean list of problematic Flash items in your tree — 

great for auditing before deletion.

🧹 Step 2: Clean Up with a Deletion Script

Once verified, we ran the following PowerShell script to safely delete the Flash items:

# Define the template Name for the Settings item
$dataFolderTemplate = "DataFolder"

# List to hold matching flashes items
$matchingFlashes = @()

# Fast query to get all Settings items under /sitecore/content with the specified template ID
$dataItems = Get-Item -Path master: -Query "fast:/sitecore/content//*[@@templatename='$dataFolderTemplate']"

foreach ($dataItem in $dataItems) {
    
    # Check if the Settings item has a flashes item under it
    $flashPath = "$($dataItem.Paths.FullPath)/Flashes"
    $flashItem = Get-Item -Path $flashPath -ErrorAction SilentlyContinue

    # If flashes item exists and matches the target template ID
    if ($flashItem -ne $null) {
        #$flashItem | Set-ItemTemplate -Template $targetTemplateId
        #Publish-Item -Item $flashItem -Target "web" -Recurse
        
        $matchingFlashes += $flashItem
        $flashItem | Remove-Item
        #Write-Host "  Found flashes: $($flashItem.Paths.FullPath)"
    }
    else{
        Write-Host " Not Found flashes: $($dataItem.Paths.FullPath)"
    }
}

# Output matched flashes items
#$matchingFlashes | Select-Object Name, TemplateName, @{Name="Path";Expression={$_.Paths.FullPath}}
$matchingFlashes | Show-ListView -Property Name, TemplateName, @{Name="Path";Expression={$_.Paths.FullPath}} -Title "Flash under Home"
# Show total count of matching $matchingFlashescts items
Write-Host ""
Write-Host "Total matching flashes items: $($matchingFlashes.Count)" -ForegroundColor Green

🎯 This script saved us hours of manual work and helped ensure consistency across all environments.

🎯 Bonus: Target Specific Items If Needed

Need to delete a specific item? You can tweak the $sitecoreItemPath in the script:

$sitecoreItemPath = "/sitecore/content/your-specific-item-path"

💡 This flexibility makes it easy to manage exceptions or troubleshoot individual issues without running global deletions.

🧠 Lessons Learned

• Automate early. Don’t wait until the cleanup becomes overwhelming.
• PowerShell is your best friend for large-scale Sitecore environments.
• Always audit before deleting — especially post-upgrade when things can be unpredictable.
• SXA upgrades may leave artifacts, so include this check in your post-upgrade checklist.

🙌 Final Thoughts

If you’re upgrading Sitecore (or planning to), keep PowerShell in your toolkit. It’s not just a scripting language — it’s your automation Swiss Army knife 🔧 for Sitecore maintenance.

These scripts helped us clean up 160+ websites in minutes — not hours or days.

🗣️ Over to You!

Have you faced a similar issue post-upgrade?
 Do you have other cleanup tips or automation tricks?
 Drop your thoughts in the comments — I’d love to learn from your experience!

🔗 Script Reference:
 GitHub — DeleteFlashesItem.ps1

📌 Stay tuned for more Sitecore insights, real-world fixes, and automation guides.

Till then, happy Sitecoring! 💙

Solving Search Result Issues After Upgrading to Sitecore 10.4

Hey everyone! 👋

As you might have seen in some of our previous blogs, we’ve shared quite a bit about upgrading Sitecore versions. Well, we recently made the jump from Sitecore 10.1 to 10.4, and just like any major upgrade, we encountered a few bumps along the way. But don’t worry—we’re here to share one of the issues we ran into and how we managed to solve it. So, let’s dive in!

The Problem: Search Results Vanishing After the Upgrade

After upgrading Sitecore, everything seemed to go smoothly at first. But then, some of our websites (we have over 170 websites hosted in Sitecore) suddenly stopped showing search results. Some sites were working just fine, but others? Not so much. 🤔

As you can imagine, this was pretty concerning. We started investigating the issue to figure out if it was related to the upgrade itself or some recent configuration changes. So, we dug into the logs and checked the configurations.

Digging Deeper: What We Found

After some digging, we discovered something interesting: our search page was using a custom index, and the results were relying on a field called sxacontext. But guess what? This field was missing in the custom indexes after the upgrade.

So, what’s going on here?

Well, it turns out that the fields were no longer present in the default index configuration. Instead, they were added to the individual SXA indexes like sxa_master_index and sxa_web_index. Since our search page depended on the sxacontext field within our custom site-specific indexes, the missing field was the culprit. 🚨

What Happened in Sitecore 10.3 and Beyond?

Here’s where things got a bit tricky: In SXA version 10.3, a few SXA computed fields were removed from the defaultSolrIndexConfiguration. This change wasn’t really a problem for the default SXA indexes, but for custom indexes like ours, it caused issues—especially when relying on fields like sxacontext.

The Fix: Restoring the Missing Fields

We figured out that the best way to resolve the issue was to re-add the missing fields back into the default Solr index configuration. After a bit of trial and error, we managed to update the configuration so that the custom index could properly use those fields again.

Here’s what our updated defaultSolrIndexConfiguration looks like now:

Updated Default Solr Index Configuration:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/">
  <sitecore search:require="solr">
    <contentSearch>
      <indexConfigurations>
        <defaultSolrIndexConfiguration type="Sitecore.ContentSearch.SolrProvider.SolrIndexConfiguration, Sitecore.ContentSearch.SolrProvider" >
          <documentOptions type="Sitecore.ContentSearch.SolrProvider.SolrDocumentBuilderOptions, Sitecore.ContentSearch.SolrProvider">
           
            <fields hint="raw:AddComputedIndexField">
               
                <field fieldName="site" returnType="stringCollection">Sitecore.XA.Foundation.Search.ComputedFields.Site, Sitecore.XA.Foundation.Search</field>
                <field fieldName="sxacontent" returnType="textCollection" type="Sitecore.XA.Foundation.Search.ComputedFields.AggregatedContent, Sitecore.XA.Foundation.Search">
                    <mediaIndexing ref="contentSearch/indexConfigurations/defaultSolrIndexConfiguration/mediaIndexing"/>
                </field>
                <field fieldName="haslayout" returnType="bool">Sitecore.XA.Foundation.Search.ComputedFields.HasLayout, Sitecore.XA.Foundation.Search</field>
                <field fieldName="searchable">Sitecore.XA.Foundation.Search.ComputedFields.Searchable, Sitecore.XA.Foundation.Search</field>
                <field fieldName="parentname" returnType="string">Sitecore.XA.Foundation.Search.ComputedFields.ParentName, Sitecore.XA.Foundation.Search</field>
                <field fieldName="level" returnType="int">Sitecore.XA.Foundation.Search.ComputedFields.Level, Sitecore.XA.Foundation.Search</field>
                <field fieldName="parenttemplate" returnType="string">Sitecore.XA.Foundation.Search.ComputedFields.ParentTemplate, Sitecore.XA.Foundation.Search</field>
                <field fieldName="inheritance" returnType="stringCollection" type="Sitecore.XA.Foundation.Search.ComputedFields.Inheritance, Sitecore.XA.Foundation.Search"/>
            </fields>
          </documentOptions>
        </defaultSolrIndexConfiguration>
      </indexConfigurations>
    </contentSearch>
  </sitecore>
</configuration>

The Result: Success!

After making these updates, search results started showing up again. 🎉

So, if anyone else runs into this issue—where search results are missing, or if certain fields are not showing up because they were moved to specific indexes (like we saw with sxacontext)—this configuration change should get things back on track.

Conclusion: Key Takeaways

Upgrading Sitecore can sometimes be a bit tricky, but with the right troubleshooting steps, most issues are solvable! Here’s what we learned from this experience:

1. Always double-check your index configurations after an upgrade, especially if you use custom indexes.

2. Look out for missing fields—they could be causing issues in unexpected places.

3. Update your configuration files to reintroduce any fields that might have been removed or moved to other indexes (like the SXA computed fields).

If you’re facing a similar issue after an upgrade, don’t panic. Follow the steps we took, and you should be able to get your search results back up and running.

Have you encountered any issues after upgrading to Sitecore 10.4? Drop a comment below or reach out if you need help! We’d love to hear about your experience. 😊

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.

Sitecore 10.4 SXA Product Issue: Handling Japanese Characters in og:title Meta Tags

Hello All,

Upgrading a Sitecore environment can introduce powerful new features—along with the occasional unexpected quirk. After recently upgrading our Sitecore instance from 10.1 to 10.4, we encountered a curious issue with Japanese language support in Open Graph meta tags, specifically in the og:title and og:description fields.

In this post, I’ll share what we observed, how we investigated it, and what we learned from Sitecore Support. This is especially relevant for teams working with multilingual Sitecore implementations using SXA.

---

🐞 The Issue: Encoded Characters in og:title for Japanese Content

Our website is primarily in Japanese. Post-upgrade, we found that Japanese text displayed properly on the page and in the <title> tag, but the same text looked strangely encoded in the page source when rendered inside og:title and og:description meta tags.

🔍 Example:

• Expected (in CMS and browser preview):
  og:title: レパーサ

• Actual (in page source):
  og:title: レパーサ

This appeared to be a character encoding issue. The Japanese text was rendered as HTML entities (numeric character references), making it unreadable in the raw HTML.

---

💡 What’s Actually Happening?

• Webpage Display: Japanese characters show correctly in the visible UI and browser tab.

• HTML Source View: Open Graph meta tags are HTML-encoded (e.g., レ for “レ”).

• Impact Scope: Only affects Open Graph meta tags; other fields are rendered as expected.

---

🔎 Investigation and Sitecore Support Findings

After escalating the issue to Sitecore Support and sharing reproducible examples:

• Reproducibility: Sitecore confirmed the issue occurs when non-Latin characters are used in Open Graph fields—particularly on pages set to English language.

• Bug ID: The issue has been registered as a known bug under SXA-8361.

• Severity: It’s considered cosmetic—while the source code looks odd, browsers and social media platforms render the characters correctly.

• Next Steps: Sitecore asked us to evaluate the urgency of a fix, since the bug doesn’t impact how content is displayed or shared.

---

🤔 Why Does This Happen?

Sitecore (like many CMS platforms) sometimes HTML-encodes non-ASCII characters in meta tag content to ensure compatibility with all HTML parsers. While this approach works functionally, it creates visually confusing source code for anyone inspecting it.

Fortunately, most platforms and scrapers (Facebook, Twitter, LinkedIn, etc.) automatically decode these entities when rendering shared content.

---

⚠️ Should You Be Concerned?

Short Answer: Not in most cases.

✅ You’re likely fine if:

• Browsers display content as expected.

• Social media previews correctly render Japanese characters.

• Search engines can interpret both raw Unicode and HTML-encoded entities, so there’s no SEO penalty.

❗ You should test more thoroughly if:

• Your systems rely on custom integrations, analytics scripts, or scrapers that directly parse meta tags from the source and expect raw Unicode.

---

🛠️ What Can You Do?

Here are a few steps to manage the situation:

• Track the Bug: Follow the progress of SXA-8361 via Sitecore Support.

• Test Social Sharing: Use tools like Facebook Sharing Debugger or Twitter Card Validator to preview how content appears when shared.

• Communicate Internally: Inform developers, QA, and content teams that this is a known product issue with no immediate functional impact.

• Customization (Advanced Option): If raw Unicode output is absolutely essential for business needs, consider customizing SXA’s meta tag rendering pipeline—but weigh the long-term maintenance cost.

---

🧾 Conclusion

Upgrading to Sitecore 10.4 helped us unlock new capabilities, but also revealed some localized content quirks. Seeing Japanese characters encoded in Open Graph tags may feel concerning, but it’s largely a cosmetic issue.

Sitecore has acknowledged and logged the bug. For now, most users and platforms will experience your Japanese content correctly—even if the page source looks messy.

If you’ve encountered similar localization issues post-upgrade or have advice to share, please drop a comment below or connect with us. Sharing knowledge helps strengthen the whole Sitecore community.

Note: I will share the solution as soon as I receive an update from the Sitecore Product Team.

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.

Upgrading Sitecore from 10.1 to 10.4: Overcoming SXA Module Challenges

 

 Hello All,

Upgrading Sitecore from version 10.1 to 10.4 can be a significant step forward in leveraging the latest features and improvements. However, during our recent upgrade, we encountered an issue while upgrading the Sitecore Experience Accelerator (SXA) module. This post outlines the problem we faced and the solution that ultimately resolved the issue.

The Upgrade Process

We followed the official Sitecore SXA 10.4 upgrade guide, which can be found here. The guide provides a step-by-step approach to upgrading the SXA module, ensuring that all necessary components are updated correctly.

The Issue: Step 4 "Update Existing Content"

The problem arose during the fourth step of the upgrade process, "Update existing content." After upgrading Sitecore from 10.1.2 to 10.4, we attempted to upgrade the Sitecore SXA content by clicking the upgrade button. Unfortunately, this action resulted in an error.

Error Description:

• A PowerShell pop-up appeared without any content.
• Some sample screenshots:

Here below list of steps after click on upgrade :

Only one left apart from that all completed successfully.

Powershell pop up without any content:

Troubleshooting and Solution

Our team, along with Sitecore support, conducted extensive troubleshooting to identify the root cause of the issue. After a thorough investigation, we discovered that broken links at one of the website tenant levels were causing the problem.

Steps Taken to Resolve the Issue:

1. Identify Broken Links: We meticulously checked the content for broken links within the affected tenant.
2. Update Links: Once identified, we updated the broken links to ensure they pointed to valid content.
3. Reattempt Upgrade: After fixing the broken links, we reattempted the upgrade process.

This approach successfully resolved the issue, allowing us to complete the SXA module upgrade without further errors.

Key Takeaways

• Thorough Content Review: Before initiating the upgrade, ensure that all content, especially links, is intact and functional.
• Collaborative Troubleshooting: Working closely with Sitecore support can expedite the resolution of complex issues.
• Documentation: Always refer to the official upgrade guides and keep detailed records of any deviations or issues encountered during the process.

Conclusion

Upgrading Sitecore and its modules can present challenges, but with careful planning and thorough troubleshooting, these can be overcome. Our experience highlights the importance of detailed content review and collaboration with support teams to ensure a smooth upgrade process.

If you have any questions or need further assistance with your Sitecore upgrade, feel free to reach out!

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.

 

 

Resolving Workflow Issues in Sitecore Custom Code Execution

 Hello All,

In our recent project, we encountered a perplexing issue where an item in draft state was being published to the web when our custom code was executed. Interestingly, during normal publishing, the workflow was respected, and the item remained in draft state as expected. This inconsistency led us to investigate further and seek help from the Sitecore community.

The Issue

Our custom code was causing items in draft state to be published, bypassing the workflow state. This was not the case with normal publishing, where the workflow was correctly followed. The challenge was to understand why the workflow state was not being respected when using custom code.

Community Insight

After extensive investigation, we posted our query on Sitecore Stack Exchange and received a prompt and insightful response. The key points from the answer were:

1. Execution Context: The custom code might be executed as a scheduled task or something similar. These jobs run in the context of the "scheduler" site, which does not respect workflows by default.
2. Site Configuration: To ensure workflows are respected, you need to either select a different site to run in context of or set the "scheduler" site to enable workflows in your site configuration.
3. SiteContextSwitcher: The recommended solution is to use a SiteContextSwitcher to change to the "shell" site within your code. This ensures that the workflow is enabled and respected during the execution of your custom code.

Implementing the Solution

To resolve the issue, we implemented the suggested solution using the SiteContextSwitcher. Here’s how you can do it:

 

C#

// Code Generated by Sidekick is for learning and experimentation purposes only. using(newSiteContextSwitcher(SiteContextFactory.GetSiteContext("shell")))
{
    // Perform your publish logic here

}

// Alternativelyusing(newSiteContextSwitcher(SiteContext.GetSite("shell")))
{
    // Perform your publishing logic here

}

By switching the site context to "shell", we ensured that the workflow state was respected, and items in draft state were not published prematurely.

Additional Resources

For more detailed information and further reference, you can visit the original Sitecore Stack Exchange post here.

Conclusion

This experience highlighted the importance of understanding the execution context in Sitecore and how it can impact workflow behavior. By leveraging the community's expertise and implementing the SiteContextSwitcher, we were able to resolve the issue and ensure our custom code respected the workflow state.

We hope this post helps others facing similar issues and encourages them to seek support from the vibrant Sitecore community.

I hope you enjoy this Sitecore blog. Stay tuned for more Sitecore related articles.

Till that happy Sitecoring :)

Please leave your comments or share this article if it’s useful for you.