Resolving Multiple HTTPS Entries in Sitemap

Issue Observed:

During a recent project, I observed that multiple HTTPS entries were being generated in the sitemap. This issue not only caused redundancy but also had potential implications for SEO and website performance.

After a detailed investigation, I determined that the problem was related to incorrect configuration settings within Sitecore.

Root Cause Analysis

In Sitecore, the configuration for each site defines how URLs are generated, including protocol and host information. The issue was traced to the following path:

/sitecore/content/Site/Settings/Site Grouping/Site1

Within this configuration, the Target Hostname field included the HTTPS protocol, which resulted in duplicate entries being created in the sitemap.

For example:

https://www.example.com

When the sitemap was generated, this setting caused the URLs to be prefixed incorrectly, leading to multiple instances of HTTPS URLs appearing.

Solution

The fix for this issue was straightforward and involved modifying the Target Hostname setting. Here’s how it was resolved:

1. Navigate to the Site Settings:

   • Go to: /sitecore/content/Site/Settings/Site Grouping/Site1

2. Correct the Target Hostname:

   • Remove the HTTPS prefix from the Target Hostname field.
   • Instead of: https://www.example.com
   • Use: www.example.com

3. Save and Publish the changes to ensure they take effect.

Why This Fix Works

Sitecore generates URLs dynamically based on the Target Hostname configuration. By including the protocol (https://) directly in the Target Hostname field, Sitecore was misinterpreting the setting and creating redundant HTTPS entries.

By specifying only the hostname (www.example.com), Sitecore uses the appropriate protocol based on other configurations, ensuring consistent and accurate URL generation in the sitemap.

Results

After implementing this change:

• The sitemap no longer displayed duplicate HTTPS entries.
• URL generation was consistent and aligned with best practices for SEO.
• The overall sitemap was clean, accurate, and free of redundancy.

Key Takeaways

• Check Hostname Settings: Always ensure the Target Hostname field contains only the hostname, without protocol prefixes.
• Follow Best Practices: Let Sitecore handle protocol resolution based on your site's configurations for HTTP and HTTPS.
• Regular Sitemap Audits: Periodically review your sitemap to identify and address any anomalies that may impact SEO.

By maintaining proper settings in Sitecore, you can avoid sitemap issues and ensure a seamless experience for both search engines and users.

For any additional queries or troubleshooting assistance, feel free to leave a comment or reach out. Happy Sitecore-ing!

Resolving Static Asset Updates in Vercel for Sitecore XM Cloud Front-End Deployments

Recently, while working on a Sitecore XM Cloud project with a front-end application hosted on Vercel, I encountered an issue where static assets like CSS and images were not updating after a code deployment. This problem persisted despite the deployment process being successfully triggered. Here’s a breakdown of the scenario and how the issue was resolved.

The Problem

After deploying the front-end application to Vercel, the changes made to static files such as CSS and images were not reflected in the live application. Instead, the site continued to serve older versions of these assets. However, the rendering host used for editors in the XM Cloud instance did not exhibit this issue, which added to the complexity of the problem.

Investigating the Issue

The deployment process followed the official Vercel deployment guide for Sitecore XM Cloud front-end applications. Key areas of focus during the investigation included:

1. Repository Configuration: Verifying that the connected Git repository for the Vercel front-end application was correctly updated with the changes.
2. Asset Delivery: Understanding how Vercel handles static files during builds and deployments.
3. XM Cloud Rendering Host: Confirming whether the issue was isolated to Vercel or if it also affected the rendering host in XM Cloud.

Root Cause

The root cause was identified as a result of a new "protected assets" feature introduced by Vercel. This feature restricts access to certain assets, making them unavailable publicly by default. Consequently, static files like CSS and images were not being updated in the deployed application.

The Solution

To resolve the issue:

1. Adjust Configuration: Ensured that the "protected assets" feature in Vercel was correctly configured to allow public access to static assets.
2. Commit Changes: Verified that all changes to the static files were committed and pushed to the Git repository connected to the Vercel project.
3. Redeploy: Triggered a new deployment to Vercel, ensuring the updated assets were included in the build process.

After implementing these steps, the front-end application successfully updated its static assets, and the latest styling and images were displayed as expected.

Key Takeaways

1. Understand Hosting Features: It’s essential to stay updated on changes and features introduced by hosting platforms like Vercel that could impact deployments.
2. Validate Deployment Processes: Double-check that all repositories and configurations align with deployment requirements, especially for headless implementations like Sitecore XM Cloud.
3. Communicate with Support: Engaging with platform support teams can expedite the resolution of complex issues.

By addressing this issue, the front-end application achieved seamless updates, ensuring consistency between deployments and live user experiences. Sharing this resolution may help others facing similar challenges while working with Sitecore XM Cloud and Vercel.

Resolving a Common Configuration Issue in Sitecore XM Cloud with Next.js

Recently I found an issue while working with a Sitecore XM Cloud environment integrated with a Next.js application. The problem manifested when attempting to open the Pages editor, leading to the following error:

Error Rendering Rendering:

No JavaScript render engine factory was found for the https engine type.
Check the getRenderEngineFactory pipeline to ensure that a factory is returned for 
the https engine type.
Also, check the spelling of the engine type name to ensure it matches the type being 
requested.

This error stemmed from an incorrect configuration setting in the CSR.Project.Common.Multisite.config file. Specifically, the serverSideRenderingEngine was mistakenly set to "https", which is not a valid rendering engine type in Sitecore's default configuration.

Root Cause

The serverSideRenderingEngine setting in Sitecore configurations specifies the rendering engine type used for server-side rendering. According to the Sitecore documentation on HTTP Rendering Engine, the supported rendering engines include http, but not https. Configuring an unsupported value, such as https, caused the system to fail when resolving the render engine.

Solution

To resolve the issue:

1. The value of serverSideRenderingEngine was changed from "https" to "http" in the configuration file.
2. The updated configuration was deployed to the XM Cloud environment.
3. After redeploying, the Pages editor was tested, and the error no longer occurred.

Here’s the corrected snippet from the configuration file:

xml

<setting name="serverSideRenderingEngine" value="http" />

Lessons Learned

1. Thorough Documentation Review: Always refer to the official documentation when dealing with configuration settings to avoid introducing unsupported values.
2. Testing in Staging: Deploy configuration changes to a staging environment first to validate functionality before pushing them to production.
3. Collaboration with Support: Leveraging the expertise of Sitecore Support helped identify and confirm the root cause efficiently.

Final Thoughts

This experience underscored the importance of precision in configurations when working with Sitecore XM Cloud and Next.js. Missteps like these, although minor, can significantly impact functionality. By sharing this resolution, I hope to help others who might encounter similar issues.

As always, I remain committed to contributing to the Sitecore community by sharing insights and solutions gained from real-world scenarios. Let's continue innovating and overcoming challenges together!

If you've faced a similar issue or have further insights, feel free to share your thoughts below.

Resolving "Valid value for rootItemId not provided" Error in Sitecore XP and Nex.jss Setup

Recenlty, I encountered an error that might be familiar to Sitecore XP and Nex.jss users: "Error: Valid value for rootItemId not provided and failed to auto-resolve app root item." In this blog post, I'll share the solution to this issue, providing step-by-step guidance to address it.

The Error: Upon initiating the client setup, the mentioned error surfaced, indicating a missing or incorrectly configured rootItemId. The solution to this problem lies within the Sitecore environment, specifically in the site group settings.

Solution Steps: To resolve the "Valid value for rootItemId not provided" error, follow these steps:

Access Sitecore CMS:

Log in to your Sitecore Content Management System.

Navigate to Site Group Settings.

Go to the following location in the Content Editor: /sitecore/content/MainSite/Site1/Settings/Site Grouping/Site1.

Locate the app name field:

Once you're on the designated path, look for the field related to the application name. This is crucial for resolving the error.

Update the app name:

Provide the correct name for the app in the designated field. Ensure accuracy and consistency with your application settings.

Save Changes:

After updating the app name, save the changes in Sitecore. This step is essential for the changes to take effect.

Rebuild and deploy:

Depending on your setup, consider rebuilding and redeploying your Sitecore and Nex.js applications to ensure that the changes are reflected.

Verify the fix:

Finally, revisit your application and confirm that the error no longer persists. If configured correctly, the rootItemId issue should be resolved.

Conclusion: By following the outlined steps, you can successfully address the "Valid value for rootItemId not provided" error in Sitecore XP and Nex.jss setups. Keep in mind the importance of accurate app naming in the Site Group Settings, as this directly impacts the resolution of the issue.

TypeError: Cannot read properties of undefined (reading 'parents')

 

During the deployment of a Next.js application, you may encounter the error 'TypeError: Cannot read properties of undefined (reading 'parents')'. This error indicates that the code is attempting to access a property named 'parents' on an object that is undefined.

Cause of the Error

The error typically arises when the code expects an object to have a 'parents' property, but the object is either undefined or does not have that property. This can happen due to various reasons, such as:

• Incorrect or missing layout path: The layout path might be incorrect, leading to the inability to load the required components and resulting in undefined objects.

• Data fetching issues: If the code relies on data fetched from an API or other sources, any issues in fetching or processing the data can lead to undefined objects.

• Component rendering errors: Errors in component rendering can cause unexpected behaviour and result in undefined objects.

Resolving the issue

To resolve this error, you can follow these steps:

1. Verify Layout Path: Double-check the layout path to ensure it is correct and points to the intended location of the layout component.

2. Inspect Data Fetching: Check if the data fetching process is working correctly and that the fetched data is being properly parsed and assigned to the appropriate variables.

3. Review Component Rendering: Review the component rendering logic to ensure that the components are being rendered correctly and that there are no errors that might be causing unexpected behaviour.

Alternative Approaches

In addition to the above steps, you can also consider alternative approaches to address the error:

• Conditional Rendering: Implement conditional rendering to check if the object is undefined before attempting to access its properties.

• Default Values: Provide default values for the object's properties to prevent undefined values from causing errors.

• Error Handling: Implement robust error handling to gracefully handle undefined objects and prevent the application from crashing.

Conclusion

The 'TypeError: Cannot read properties of undefined (reading 'parents')' error can be resolved by carefully examining the layout path, data fetching, and component rendering logic. 

In my case I did two things, One is updated the Layout path and publish the items and second is Implemented conditional rendering considerig the experience editor mode.

Navigating Sitecore XM Cloud Prompts: Understanding Organization Tiers and Project Limits

Sitecore, a leading digital experience platform, empowers organizations to create seamless and personalized digital experiences. One of the essential features of Sitecore is the ability to organize projects into different tiers within the platform. However, users may encounter a limitation known as the "Organization Tier Project Limit," preventing them from adding more projects. In this technical blog, we'll delve into this issue, exploring its implications and offering potential solutions.

Understanding Organization Tiers:

Sitecore's organizational structure involves the use of tiers to categorize projects. The organization tier serves as the highest level, under which various projects are organized. Each tier represents a level of hierarchy within the platform, allowing for efficient management of digital assets, content, and configurations.

The Challenge: Project Limitation in the Organization Tier

Users often face a roadblock when attempting to add more projects to the organization tier. The platform imposes a project limit within this tier, hindering scalability for organizations with extensive digital initiatives. This limitation may stem from various factors, including licensing constraints, resource allocation, or architectural considerations.

Impact on Organizations:

The project limit within the organization tier can have significant implications for organizations aiming to expand their digital presence. As organizations evolve, they may require the ability to create and manage additional projects within Sitecore to accommodate new initiatives, campaigns, or product launches. The imposed limitation can impede agility and hinder the seamless execution of digital strategies.

Possible Solutions:

Review Licensing and Editions:

Ensure that your Sitecore license supports the desired number of projects within the organization tier. Different Sitecore editions may have varying limits, and upgrading to a higher edition might be a solution.

Optimize Existing Projects:

Evaluate the projects within the organization tier to identify opportunities for optimization. Removing redundant or obsolete projects can free up space for new initiatives.

Engage Sitecore Support:

If the project limitation persists, reaching out to Sitecore Support can provide insights into the specific constraints and potential solutions. Sitecore Support can offer guidance on best practices and assist in resolving licensing or configuration issues.

Conclusion:

The project limit within the Sitecore organization tier is a critical consideration for organizations seeking to scale their digital initiatives. By understanding the factors contributing to this limitation and implementing the suggested solutions, organizations can overcome challenges and continue leveraging Sitecore's powerful capabilities for creating compelling digital experiences. Regularly reviewing licensing, optimizing existing projects, and engaging with Sitecore Support are essential steps in ensuring a seamless and scalable digital experience platform.

Elevating Sitecore XM Cloud Development: Automating IIS Service Stop in Docker with Up.ps1

Efficient development workflows are essential for a seamless Sitecore XM Cloud experience, especially when working with Docker. In this blog post, we'll explore a simple yet powerful improvement to development efficiency by automating the stopping of IIS services using the Up.ps1 script in a Sitecore XM Cloud Docker environment.

Script

# Stop IIS Services

Write-Host "Stopping IIS Services" -ForegroundColor Green

try {

    # Attempt to stop IIS Service

    Invoke-Expression -Command .\scripts\StopIISServices.ps1

} catch {

    # Handle the exception if the script file doesn't exist or any other error occurs

    Write-Host "An error occurred: $($_.Exception.Message)" -ForegroundColor Red

    # You can add additional error handling or log the error here

}

Benefits

1. Time Savings:

Manually stopping IIS services can be time-consuming, especially during iterative development. Automating this process with the Up.ps1 script reduces downtime and accelerates the development cycle.

2. Consistency Across Environments:

Developers often work in varied environments. Automating the IIS service stop ensures consistency in the development process, irrespective of individual setups.

3. Error Handling:

The script incorporates error handling to gracefully manage scenarios where the StopIISServices.ps1 script is missing or if any other unexpected error occurs. This proactive approach helps developers quickly identify and resolve issues.

4. Integration with Docker Workflow:

This automation aligns seamlessly with Docker-based workflows. Whether starting or stopping containers, the Up.ps1 script becomes a central point for managing the development environment.

Implementation Steps

Ensure Proper Script Setup:

Confirm that the StopIISServices.ps1 script is correctly configured and present in the specified location.

Integrate with Docker Compose:

Incorporate the execution of Up.ps1 in your Docker Compose file. This ensures that the IIS services are automatically stopped whenever the development environment is brought up.

Conclusion

Automating the IIS service stop in Sitecore XM Cloud within a Docker environment significantly enhances development efficiency. By seamlessly integrating this functionality into the Up.ps1 script, developers can enjoy a smoother, more consistent, and error-resilient development experience. Consider implementing this enhancement in your Sitecore XM Cloud projects to streamline your Docker-based development workflows.

Here is the script for the reference -  https://drive.google.com/drive/folders/1kVrrFQiWnJ-sZT2uO3axEDPhuXALHy-_?usp=sharing

Sitecore Xm Cloud - Navigating React Hooks: Addressing useEffect Missing Dependency Warnings and Escaping Quotation Marks

 Recently I got below error while building and deploying the XM Cloud project

 +00:00|INFO|114:5  Warning: React Hook useEffect has a missing dependency: 'facets'. Either include it or remove the dependency array.  react-hooks/exhaustive-deps

39:13  Error: `"` can be escaped with `"`, `“`, `"`, `”`.  react/no-unescaped-entities

  Error: `"` can be escaped with `"`, `“`, `"`, `”`.  react/no-unescaped-entities

to fix this issue for temprary I disabled below settings.

 "@typescript-eslint/no-unused-vars": "off",

    "@typescript-eslint/no-explicit-any": "off",

    "react/no-unescaped-entities": "off",

    "@next/next/no-page-custom-font": "off",

Fixing Package Installation Error: Version Conflict in Sitecore CLI

During the initial stages of building my Sitecore project using Bitbucket pipelines, I encountered a critical roadblock: a version conflict with the sitecore.cli package. The error message indicated that the manifest file already contained version 5.1.25, conflicting with the desired version, 5.2.113. To address this, a targeted fix involved updating the dotnet-tools.json file manually. In this technical account, I'll provide a detailed walkthrough of this fix.

The Issue: Version Mismatch in sitecore.cli

The error message "Cannot add package. Manifest file already contains version 5.1.25 of the package sitecore.cli" pinpointed a version conflict during the build process. The challenge was to rectify this conflict, ensuring alignment with the required version, 5.2.113.

The Fix: Updating dotnet-tools.json

1. Locate dotnet-tools.json

The first step was to navigate to the directory specified in the error message, typically /opt/atlassian/pipelines/agent/build/.config/. Here, the dotnet-tools.json file resides.

2. Open for Editing

Once located, I opened the dotnet-tools.json file for editing. This can be achieved through any preferred text editor or integrated development environment (IDE).

3. Update sitecore.cli Version

Within the file, I identified the entry for sitecore.cli and manually updated the version number to 5.2.113. This involved changing the existing version, usually set at 5.1.25, to the required version.

4. Save Changes

After making the necessary adjustment, I saved the changes to the dotnet-tools.json file, ensuring that the updated version number for sitecore.cli was persisted.

5. Retry Package Installation

With the file updated, I retried the package installation process. The purpose was to confirm that the correct version, 5.2.113, was now being utilized without encountering the previous version conflict.

6. Verify Compatibility

Before concluding the fix, it was imperative to verify the compatibility of version 5.2.113 with the project's requirements. This involved checking for any additional dependencies or behavioral changes.

Conclusion

By strategically editing the dotnet-tools.json file, specifically updating the version of the sitecore.cli package, the version conflict was successfully resolved. This targeted fix allowed for a seamless build process, ensuring that the correct version was utilized during the Sitecore project development within Bitbucket pipelines. The manual edit of the manifest file provides a precise solution for version conflicts, demonstrating the power of nuanced adjustments in the development workflow. As always, adapt these steps to your specific scenario and leverage the broader development community for insights and collaboration. Happy coding!

Resolving the "No CORS Policy Found" Error in Sitecore 10.3 Identity Server

Encountering the Sitecore Identity Server error, specifically the "No CORS policy found for the specified request" issue, can be a frustrating experience for developers and administrators. In this blog post, we'll delve into the details of this error and provide a practical solution to address it.

Error Details:

The error message points to a problem with the CORS (Cross-Origin Resource Sharing) policy, specifically when the request origin is set to "null," indicating that it doesn't have permission to access the resource. The log entries show the execution of the relevant endpoint in the Identity Server, followed by an unhandled exception related to a SQL Server connection issue.

Error Log:

(Sitecore Identity/AA0001) Request origin "null" does not have permission to access the resource.

(Sitecore Identity/AA0001) No CORS policy found for the specified request.

(Sitecore Identity/AA0001) Executing endpoint '"Sitecore.Plugin.IdentityServer.Controllers.AccountController.Login (Sitecore.Plugin.IdentityServer)"'

[INF] (Sitecore Identity/AA0001) Route matched with "{action = \"Login\", controller = \"Account\"}". Executing controller action...

[INF] (Sitecore Identity/AA0001) Executed action "Sitecore.Plugin.IdentityServer.Controllers.AccountController.Login (Sitecore.Plugin.IdentityServer)" in 16964.3894ms

[ERR] (Sitecore Identity/AA0001) An unhandled exception has occurred while executing the request.

System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server...

 ---> System.ComponentModel.Win32Exception (2): The system cannot find the file specified.

Solution:

To address this issue, follow these steps:

Investigate the CORS Policy:

Check your Sitecore configuration and ensure that the CORS policy is correctly configured to allow the specified request origin. Review Sitecore documentation and relevant articles to verify the proper CORS setup.

Review External Resources:

The provided Sitecore Stack Exchange link (https://sitecore.stackexchange.com/questions/19242/what-does-this-error-message-in-the-identity-server-logs-mean) can offer valuable insights into similar issues. Explore discussions and solutions from the community.

Check SQL Server Services:

In the presented solution, the root cause was identified as SQL Server services not running. Validate the status of your SQL Server services and restart them if necessary. Ensure that SQL Server is configured to allow remote connections and that the instance name is correct.

Conclusion:

Resolving the "No CORS policy found for the specified request" issue in Sitecore Identity Server involves a comprehensive approach. By investigating the CORS policy, reviewing external resources, and addressing potential SQL Server service issues, you can successfully mitigate this error. Remember to adapt these steps based on your specific environment and configurations.

Most common again - Sitecore 10.2 when running on a diff machine MSBuild: Could not locate executable.

 I got the solution from a VM and started running on my local machine and got the below error, it's the most common error and to fix it basically we need to set the correct path into the build-config file

  "MSBuildPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\MSBuild\\Current\\Bin\\msbuild.exe",

Diff system has diff VS version installed so make sure that the script has the correct path from your installed VS version

How to add new service Principal - Sitecore Next.jss (Headless) Deployment to web apps

I was using the Azure PaasS - so first we need to raise the Sitecore support ticket to generate the Service Principal.

Here are the steps - Login into the Sitecore Portal and raise the ticket under 

Make sure that this new service principal should also have a shared drive access/ blob storage so you can upload the default artifacts like Jss and SXA packages to pull and upload to the new vanila setup

Search for the option Update Access to Azure - Service Principal

This is basically automated process so the moment you raise the ticket, an automated script will be excuted and create the service principal for you.

Now, the next step is to login into the Azure portal and create a new connection

Application (client) ID: is Service Principal Id

Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\Website - Sitecore Next.jss (Headless) Deployment to web apps

 I got another error which is Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\Website

I found the issue was related to the correct path configuration in copy and upload azure pipeline

Copy step should have the correct source path/folder 

and destination path should have syntax like $(Build.ArtifactStagingDirectory)\Sitecore

and the publish artifacts should have path like this 

$(Build.ArtifactStagingDirectory)\Sitecore\cm

Copy pipeline

Upload Pipeline

After the correct configuration, I was able to resolve the issue

Couldn't find a debug log in the cache or working directory - Sitecore Next.jss (Headless) Deployment to web apps

 Recently I got this error in Azure pipeline

Although, this pipeline was working before, I made a few changes in the producation transformation file and basically it's not recongnizing those keywords

on my local I got the below eroror

The PUBLIC_URL environment variable '#{PUBLIC_URL}#' is not a valid URL.

to fix that, I have moved all my transformatio file into a new folder and replaced during the release pipelines.

Sitecore 8.1 - update configuration from multilingual to English only and handle en in the URL redirect rule

Recently, I got a request to fix an urgent issue, the alias was not working for a Sitecore instance 8.1,  I investigated this issue and found the language context got changed from en to the alias name.

How did we identify?

on the page source code, we keep the language code and while using the alias the language context got changed. I tried a lot to find the root cause that why Sitecore is changing the language to a wired language code from the alias and found that this was a known issue in Sitecore

Reference - https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB0659458

so the issue was when a letter combination that matches any of the .NET Culture Codes is in that position, it gets resolved as a language (even if the language is not registered for Sitecore XP instance) and is not used to resolve anything else (for example, an alias or an item). If a resolved language is not identified, an error similar to the following appears:

I applied the first patch to Languages.AlwaysStripLanguage to false, it worked for me but the problem was there were a few existing URLs with EN, and those started giving 404 errors.

Now, I need to keep all those URLs live,  the easiest solution was the redirect rule.

I got some good references from this link https://community.sitecore.com/community?id=community_question&sys_id=5144e3691b0770d0b8954371b24bcb9d

and finally added the below configuration on the web. config and that way we have resolved the issue.

<rewrite>

  <rules>

<rule name="English Redirect" stopProcessing="true">

<match url="^en/(.*)$" />

<action type="Redirect" url="/{R:1}" />

</rule>

  </rules>

</rewrite>

  </system.webServer>

Sitecore sorting best practices and recommendation.

Sometimes applying a simple sorting based on title can create an issue, we need to be very careful about it.

Applying sorting based on title is not going to work, strange right?

Let's see this in detail.

The title is a text general field and the tokenizer will make tokens of the value so logically you can't do sorting on this field

In case if we want to do the sorting on the title field, It's recommended to create a copy field which will basically copy the data from the title and move into the target field and make sure that the target field is a string field so it will hold the string value and sorting can be done.

Example for the text or text general field 

With string field

Solution - How to add a copy field  - Reference - https://solr.apache.org/guide/6_6/copying-fields.html

<copyField source="cat" dest="text" maxChars="30000" />

Hope this will help to others.

Docker issue when you got an existing machine which configured for a diff account

 Recently, I got a chance to work on an important project as a firefighter for 4 weeks, I got the existing machine and my first issue was related to the docker, here is my learning and details for the fix.

Error -' You are not allowed to use Docker, you must be in the "docker-users" group

I got this error while running the docker, to fix this issue I follow this link 

basically, we need to add the user to the docker-user membership 

Now, after doing that, I got a diff error, which is as below

to fix that, please make sure you do the sign-out, the restart and disconnect option will not work.

I hope that will help others.

SXA Custom Token - Best practices to include the operation correctly.

 When implementing SXA custom token, it would be good to consider the options like must, should or not, this is already part of the SXA model, so basically we need to make sure to include the below conditions.

Pass the model operation name as a parameter -

 public override void Process(ResolveSearchQueryTokensEventArgs args)

        {

            if (args.ContextItem == null)

                return;

            for (int index = 0; index < args.Models.Count; ++index)

            {

                SearchStringModel model = args.Models[index];

                if (model.Type.Equals("sxa") && this.ContainsToken(model))

                {

                    string str = model.Value.Replace(this.TokenPart, string.Empty).TrimStart('|');

                    var fieldNames = str.Split('|').ToList();

                    if (fieldNames.Any() && fieldNames.Count == 2)

                    {

                        args.Models.Insert(index, this.BuildModel(fieldNames[0], fieldNames[1], model.Operation));

                        args.Models.Remove(model);

                    }

                }

            }

        }

  protected virtual SearchStringModel BuildModel(

            string replace,

            string fieldValue, string operation)

        {

            return new SearchStringModel("custom", FormattableString.Invariant(FormattableStringFactory.Create("{0}|{1}", replace.ToLowerInvariant(), fieldValue)))

            {

                Operation = operation

            };

        }

Model operation values - Just for the reference.

SXA boosting rule - Search Box Query

 As we know that Sitecore has provided a lot of rule-based boosting options, I found the below rule very useful in a recent implementation.

We can see the appropriate logs to see that boosting is applied correctly.

2021-10-13 22:34:12.460 INFO  (qtp23211803-22) [c:sitecore_sxa_dev_master_index s:shard1 r:core_node2 x:sitecore_sxa_dev_master_index_shard1_replica_n1] o.a.s.c.S.Request [sitecore_sxa_dev_master_index_shard1_replica_n1]  webapp=/solr path=/select params={q=((((((_template:(c03a48a03baf4ba09f10774f365841a4)+OR+_template:(911e99589fa64e85901eac0e0fc96009))+AND+((_path:(0513592509aa40188c47987bc6f9236a)+AND+searchable_b:(True))+OR+(_path:(e86fa7d2714741548e25c0bcdb9217fb)+AND+searchable_b:(True))+OR+(_path:(225d1bc67544492d8d752fdaa1a7151c)+AND+searchable_b:(True))+OR+(_path:(9377586f8345460b8dd01e24a451aeb6)+AND+searchable_b:(True))))+AND+sxacontent_txm:(lifestyle~0.5))+AND+_latestversion:(True))+AND+((content_t:(*lifestyle*))^5+OR+(-_name:("")++_name:[*+TO+*])))+AND+((title_t:(*lifestyle*))^5+OR+(-_name:("")++_name:[*+TO+*])))+AND+_val_:__boost&start=0&fq=_indexname:(sitecore_sxa_dev_master_index)&sort=title_t+asc&rows=5&wt=xml&version=2.2} hits=3 status=0 QTime=17

Move Docker data to a different drive to save space from the c drive - Quick configuration.

Recently, while working on a project I found the space issue in C Drive and because of that, the docker container was getting shut down automatically.

Although the VM has good space in the d drive, I did the path change in the configuration and it basically saved my work.

How to make that change - We can directly do it from the docker UI settings option or can change the C:\ProgramData\Docker\config\daemon.json

Reference - https://github.com/docker/for-win/issues/185

Results in D Drive -