Understanding Sitecore Stream API and Its Role in Language Translation

Sitecore’s Stream API is one of the latest innovations introduced in Sitecore XM Cloud, enabling faster and more flexible content delivery. It provides a modern, high-performance API that streams content directly at the component level, allowing front-end applications like Next.js or Vercel-hosted sites to fetch only the data they need — in real time.

While the Stream API does not translate content automatically, it seamlessly supports multilingual delivery. This means if your Sitecore content items have versions in multiple languages (e.g., English, Arabic, Chinese, Japanese), the Stream API can automatically deliver the correct localized version based on the language context of the request.

For automatic translation, you can integrate the Stream API with Azure Cognitive Services Translator or other AI-based translation engines. This approach allows you to:

• Automatically translate editorial content into multiple languages.

• Store the translated versions as separate language variants within Sitecore.

• Deliver localized content efficiently through the Stream API to your front-end application.

In short, the Stream API acts as the real-time multilingual content delivery layer, while external AI translation services handle the actual language conversion and localization.

Sitecore 10.4 -Fixing Sitecore Installation Errors: .NET Hosting Bundle Download (dotnet-hosting-6.0.21) Fails with "EOF" or "400 Bad Request

When installing Sitecore XP/XM on-premises using SIF (Sitecore Installation Framework), you may run into frustrating issues during the .NET Hosting Bundle download step. The issue often looks like this:

Issue - the download link is not suported as it's tryign to find the old version 

[-------- DownloadDotNetMultiTargeting : DownloadFile ------------------------]

[DownloadDotNetMultiTargeting]:[Download] https://download.visualstudio.microsoft.com/download/pr/b50f2f63-23ed-4c96-9b38-71d319107d1b/26f8c79415eccaef1f2e0614e10cd701/dotnet-hosting-6.0.21-win.exe => C:\Users\jitus\AppData\Local\Temp\dotnet-hosting-win.exe

Error downloading https://download.visualstudio.microsoft.com/download/pr/b50f2f63-23ed-4c96-9b38-71d319107d1b/26f8c79415eccaef1f2e0614e10cd701/dotnet-hosting-6.0.21-win.exe: The underlying connection was closed: The connection was closed unexpectedly.

[TIME] 00:00:19

Error downloading https://download.visualstudio.microsoft.com/download/pr/b50f2f63-23ed-4c96-9b38-71d319107d1b/26f8c79415eccaef1f2e0614e10cd701/dotnet-hosting-6.0.21-win.exe: The underlying connection was closed: The connection was closed unexpectedly.

When I checked the URL, I got 404 to fix the issue

I replace the URL in 

Prerequisites.json

Value https://builds.dotnet.microsoft.com/dotnet/aspnetcore/Runtime/6.0.36/aspnetcore-runtime-6.0.36-win-x64.exe and that fixed the issue

XMC how to fix a network with name ABC-xmc_default exists but was not created by compose

Recently during the new XMC project setup, I got below error

 Starting Sitecore environment...

 level=warning msg="a network with name ABC-xmc_default exists but was not created by compose.\nSet `external: true` to use an existing network"

network ABC-xmc_default was found but has incorrect label com.docker.compose.network set to ""

You cannot call a method on a null-valued expression.

At C:\Projects\ABC-xmc\docker\add-host.ps1:8 char:1

+ $containerId = $containerId.Replace("failed to get console mode for s ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (:) [], ParentContainsErrorRecordException

    + FullyQualifiedErrorId : InvokeMethodOnNull

Fix

Go to your docker compose overide file and at the last add this lines

networks:

  default:

    external: true

    name: ABC-xmc_default

Handling Special Characters in Sitecore Search: Current Limitations and Challenges

I recently contacted Sitecore Support to explore whether it’s possible to configure search functionality to better handle queries containing only special characters. Specifically, I wanted to ensure that such queries return no results without requiring front-end adjustments or UI-level changes.

Current Search Behavior

At present, Sitecore’s search system does not manage this scenario effectively. When a search query consists solely of special characters, the platform doesn’t filter them out and ends up returning all results. While Sitecore's search analyzer uses a predefined list of stop words to exclude common terms, there is no equivalent mechanism to handle special characters.

Sitecore’s Response

After a detailed review, Sitecore Support confirmed that there is no built-in functionality to address this issue. Filtering out queries with only special characters is not supported out-of-the-box and would require custom development or alternative workarounds beyond Sitecore's default capabilities.

Next Steps and Considerations

Given the lack of a native solution, I have opted to close the support ticket for now. However, this is an area where Sitecore could consider future enhancements to improve search accuracy and behavior.

In the meantime, teams facing similar challenges may need to explore custom implementations or front-end validation to handle such search queries effectively.

Pages Rich Text Editor (RTE) Lacks Internal Sitecore Link Functionality

While working with the Rich Text Editor (RTE) in Pages, we noticed a limitation: it doesn’t allow the creation of internal Sitecore links. This makes it harder for the marketing team to seamlessly add internal links directly within the Pages interface, disrupting their workflow and efficiency.

Current Status

Sitecore Support has confirmed that this functionality is not currently available in the Pages RTE.

• A feature request (PGS-1236) has been created for consideration in future releases.
• In the meantime, the recommended workaround is to add internal links directly through the Content Editor.

Workaround

For now, internal links can be added by:

1. Navigating to the Content Editor.
2. Editing the Rich Text field and manually inserting internal links.

Next Steps

• Monitor the status of the feature request (PGS-1236) via the Sitecore Support portal.
• Consider educating content authors on the temporary workaround until the feature is available in Pages.

We hope to see this functionality in upcoming releases to streamline the authoring experience for internal linking directly in Pages.

Custom Class Not Retained in Rich Text Editor (RTE) in Page Editor Mode (XMCloud)

In Sitecore XM Cloud's Page Editor, the Rich Text Editor (RTE) has an issue where custom class attributes applied to HTML elements, such as a <span>, are not preserved. After saving and reopening the RTE, these elements are automatically converted to <p> tags, causing the custom class to be stripped away.

Example:

Input:

<span class="small-text">Sample Text</span>

After saving and reopening:

<p>Sample Text</p>

Investigation and Findings

• The issue occurs exclusively in Pages' RTE, which uses Quill.js as the editor.
• In the Content Editor's RTE, custom attributes like <span> and class are preserved as expected.
• This behavior is linked to Quill's optimization process, which standardizes and simplifies HTML during editing.

Recommended Resolution

To address this issue, Sitecore Support recommends switching to the latest CKEditor RTE, which resolves the problem and supports retaining custom attributes like classes.

Steps to Enable CKEditor in Sitecore XM Cloud

1. Update Configuration:

   • Replace Quill.js with CKEditor as the default Rich Text Editor for the Page Editor.

2. Validate Custom HTML:

   • Ensure that CKEditor preserves custom HTML elements and attributes in your environment.

3. Test and Deploy:

   • Test the new RTE configuration thoroughly in a staging environment before rolling it out to production.

For detailed instructions, refer to the official Sitecore documentation: Enabling CKEditor in Sitecore XM Cloud.

Workaround

If switching to CKEditor is not immediately feasible, you can manage custom HTML via the Content Editor RTE, where the issue does not occur.

Outcome

By implementing CKEditor, you can retain custom classes and resolve this limitation in the Page Editor's RTE, ensuring better flexibility and alignment with custom styling requirements.

Sitecore API Pagination and Sorting Errors

The Sitecore API was experiencing critical issues impacting pagination and sorting functionalities. Whenever users attempted to navigate to subsequent pages or apply sorting, the API returned internal server errors (500), rendering the features unusable.

Issue Summary

1. Internal Server Errors (500):
   When pagination or sorting requests were sent, the API intermittently responded with:

   
   
   {
       "widgets": [
           {
               "rfk_id": "test_widget_1",
               "type": "content_grid",
               "errors": [
                   {
                       "message": "Internal Server Error",
                       "code": 1001,
                       "type": "internal_server_error",
                       "severity": "HIGH"
                   }
               ]
           }
       ]
   }
   

2. Sorting Failures:
   Sorting configurations such as title_asc_asc or title_desc_desc failed to produce expected results. Responses either returned incorrect data or triggered the same server error.

3. Inconsistent Pagination Behavior:
   For example, attempting to navigate to page 2 through /search?page=2 consistently produced the following:

   
   {
       "message": "Internal Server Error",
       "code": 1001,
       "type": "internal_server_error"
   }
   

Root Cause (Identified by Sitecore Team)

The Sitecore support team determined that the issue was caused by:

1. A combination of boost rules and pagination settings that conflicted under certain API configurations.
2. Faulty API handling logic when fetching large datasets while applying custom sorting and pagination rules.

Resolution

1. System Update:
   Sitecore implemented a patch to rectify how boost rules interact with pagination requests.
2. Configuration Adjustments:
   The team updated internal settings to ensure sorting worked seamlessly with pagination.
3. Verification:
   After the fix was deployed, multiple test cases were executed to confirm that:
   • Pagination worked correctly.
   • Sorting options applied accurately without triggering server errors.