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.