Category: Technology

Sitecore Experience Platform (XP) 10.4 Released: XP is still far from being extinct!

Sitecore released Sitecore Experience Platform 10.4 at the end of April 2024 and the setup files are available to download from the following link: Sitecore 10.4 Downloads.
The buzz in the market was that it may be curtains for Sitecore XP looking at the push for the cloud migration to Sitecore SAAS or the Sitecore XM Cloud. However, the release of Sitecore XP 10.4 indicates that our favourite CMS Sitecore Experience Platform (XP) is still far from being dead.

Multiple applications that are currently on Sitecore XP 10.2 were looking forward to this particular release of Sitecore XP as the Mainstream Support for Sitecore XP 10.2 ends in Dec 2024. A quick upgrade to Sitecore XP 10.4 would be on the cards for these implementations in the second half of 2024. The Sitecore Support Information for all the Sitecore Versions can be found at the following link: Sitecore Product Support Lifecycle

This blog post gives an overview of the important and significant improvements/features available in this version. The detailed information can be found from the following Sitecore link: Sitecore 10.4 Release Notes

1. Support for ltsc2022 Windows containers:

This is relevant if you are using a containerized setup. With Sitecore 10.4, they have extended the support for ltsc2022 Windows containers. For customers with ltsc2019 and planning to upgrade to Sitecore 10.4, the container images for ltsc2019 haven’t yet been released (as of the end of April 2024) by Sitecore but will be released in the upcoming weeks. If you are wondering what LTSC means then it is an acronym for Long-Term Servicing Channel used by Microsoft for licensing Windows Server. You may read about LTSC here: Windows Server Servicing Channels.

2. Create custom languages that are not registered in .NET (en-eu):

In the previous Sitecore versions, if you had to add languages that were not registered in .NET, you had to customize the application to get it working. In Sitecore 10.4, you may create any language version by combining the ISO code with the region/country code without the need for any customization.

The languages like en-eu (English Europe), en-mx (English Mexico), en-cl (English Chile), etc. can now be added without any customization in Sitecore XP 10.4.

3. Compatibility with SQL Server 2022:

With Sitecore XP 10.4, you may use SQL Server 2022 for the databases. The latest version of SQL Server supported by the previous version of Sitecore XP 10.3 was Microsoft SQL Server 2019.

4. Implementation of Solr soft commits:

The commit operation in Solr is quite critical as any data that is sent to Solr won’t be searchable until it has been committed. The commit strategy is at the core which determines when the document additions, deletions or changes are available for searching. The Soft Commit strategy gives us faster visibility of content and hence we can expect better performance in terms of Solr indexing.

5. XM to XM Cloud Content Migration tool:

The Sitecore XM to XM Cloud Content Migration tool is a readymade application from Sitecore that can be used to move Content, Media Items and User Data from an on-premises XM instance to an XM Cloud environment. You may use this tool for migrating from Sitecore XP to Sitecore XM Cloud too but it would migrate only the content portion of XM.
Although this is marketed as a feature of Sitecore XP 10.4, this has been available for a while for Sitecore Versions from 10.1 and later.

6. xDB to CDP Migration Tool:

This is a readymade tool released and maintained by Sitecore which can be used for transferring contact facets to Sitecore’s CDP and Personalize products, and also via Sitecore Connect to external systems.
Although this is again marketed as a feature of Sitecore XP 10.4, this has been available for a while for Sitecore Versions from 9 and later.

7. OOTB support for .ico files in the Media Library:

You may now upload .ico files usually used for favicons in the Media Library without any customization. In the earlier versions, this was not supported OOTB and we had to add patch config entries.
If you have already done this customization in your current implementation and planning for an upgrade to Sitecore XP 10.4, make a note to remove this customization to avoid redundant config code. Search for the following line in your solution and remove the entire customized section for .ico files.

<mediaType name="icon" extensions="ico">
---
</mediaType>

In the Vanilla Sitecore instance of Sitecore 10.4, you can find this entry for .ico file in the file: /App_config/Sitecore.config.

7. [BUG] BlobProviderException thrown when media is detached from an item and the item is published:

Although saving the media item without the media shows a warning, this issue might be reported by the content authors when they publish with related items and the Media Item without the media is related to their current item. This was a bad Content Editor experience and Content Editors may feel something is critically wrong with the system and report it. This issue has been taken care of in the current update.

Important Update: The Sitecore Downloads page has been migrated:

Starting from Sitecore 10.4 version, the Sitecore Downloads would be migrated from https://dev.sitecore.net/Downloads.aspx to https://developers.sitecore.com/downloads. The old page would be deprecated and wouldn’t receive any updates. Please note when you do a web search for Sitecore downloads, you may still be taken to the old downloads page due to the SEO not being updated but I would recommend downloading the files from the new portal only as the latest data and files would be updated on this portal alone.

This completes the blog post highlighting the significant changes in Sitecore XP 10.4. I hope they don’t retire the Sitecore Experience Platform (XP) anytime soon and provide continuous support in the future too.

About me:

Vivek Anandan Venugopalan

Hi! I’m a Sitecore Certified Advanced Developer from India with 8+ years of Experience working with Sitecore. I am an avid Railfan and love Cycling and Traveling. I also have a couple of travel blogs which can be checked by clicking on the first couple of links below.

Azure DevOps with Sitecore Series: Post 2 – Understanding the Basics of Build and Release Pipelines

This is the second post in my Azure DevOps with Sitecore Series. The first post can be checked from the following link: Azure DevOps with Sitecore Series: Post 1 – Getting the Azure Repository Setup Right

In this blog post, I will explain the basics of Build and Release Pipelines which are the core concepts in any DevOps system. I will be diving into very basic to make the concepts clear for anyone new to the Azure DevOps world.

What is Continuous Integration (CI):

You would find many explanations of these concepts in formal complex words but I am going to keep it simple here within the context of Sitecore and C#. Continuous Integration means that the code that you commit in the Source Control System (eg. GITHUB) gets compiled on the fly and generates the files required for deployment (DLLs, View Files, Config Files, etc.).

Think of Continuous Integration as the process where you trigger a local Visual Studio build from a particular branch which contains the code. The following process happens:

Code Compilation:
The code gets compiled.
Execution of Unit Tests:
The Unit Tests in the Solution (if any) are executed.
Output Files:
It generates the output files that can be deployed to the website.

In a nutshell, you are producing the compiled code that is unit tested and free of any (compilation) errors which is ready for deployment.

Artifacts:

Artifact is something that you are already aware of but it is just a different terminology. When you build the code in a solution, the output that is produced by the build is called an Artifact. The compiled code that is unit tested and free of any (compilation) errors is the Artifact. In a traditional Sitecore setup, typically four artifacts would be generated for a deployment to a single environment:

CM Artifact
CD Artifact
XConnect Artifact
TDS or the Sitecore Items Artifact

You would be using the Build Pipelines for Continuous Integration (CI) or building the code and generating the required artifacts. In the Azure DevOps Portal, the Build Pipelines can be accessed by hovering over the Rocket Icon and clicking on the Pipelines link as shown below:

What is Continuous Delivery (CD):

To keep it simple, Continuous Delivery (CD) is the process of fetching the artifacts generated by the build pipeline and dumping/deploying them to a specific website folder.

The Release Pipelines can be accessed by hovering over the Rocket Icon and clicking on the Releases link as shown below:

Methods to Develop Build and Release Pipelines:

You may use the following methods to develop the pipelines:

Classic Build Pipelines
Classic Release Pipelines
YAML Build Pipelines
YAML Release Pipelines

It is not mandatory to create both Build and Release pipelines with the same method. You may even have an implementation where the Build Pipeline developed with YAML while the Release Pipeline being developed in a Classic Way or vice versa.

If you are starting afresh, it would be better to develop both the pipelines with the same method to maintain consistency. YAML Pipelines are the new addition to Azure DevOps and provide additional features that may be leveraged so it is adviced to use YAML Pipelines if you are starting new with Azure DevOps or even migrating to Azure DevOps from a CI CD tool like TeamCity, Jenkins, etc.

Classic Way of Developing Pipelines or the Classic Pipelines:

Classic Pipelines are typically developed in the GUI Editor. You search for steps in the search box and add the required step to the pipeline. In a traditional Sitecore setup in Classic setup for a Build Pipeline, you would usually develop one pipeline for building the code for each of your environment like if you have 4 environments, you would develop 4 classic build pipelines:

CodeBuild-DEV
CodeBuild-TEST
CodeBuild-UAT
CodeBuild-Production

The YAML Pipelines:

YAML (Yet Another Markup Language) Pipelines are developed with YAML Code. YAML Pipelines are the typical example of IAC (Infrastructure As Code) where you provision the environment using code. Every step that is used in the pipeline is developed through code.

YAML pipelines have the following advantages:

1. Easier Replication:

YAML Pipelines are easier to replicate on a new environment or even in a different DevOps application.

2. Maintainability:

As the YAML Pipelines are developed using code, they are easier to maintain.

3. Code Reviews:

Code Reviews can be performed before any change is committed

4. Better Versioning:

Although Versioning is available even in Classic Pipelines but managing the code versions is more convenient with YAML.

A typical block of code from a YAML Pipeline is listed below:

pool:
  name: MyAppPoolName 

jobs:
  - job: BuildMyApp
    displayName: Build the code for MyApp
    steps: 
    - task: VSBuild@1
      displayName: CM.Build
      inputs:
        solution: 'Source/MyApp.Web.sln'
        msbuildArgs: '/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:publishUrl="$(Build.ArtifactStagingDirectory)" /p:RunCodeAnalysis=false /p:Platform="Any CPU"'
        configuration: 'DEV.CM'
        vsVersion: "17.0"

    - task: PublishBuildArtifacts@1
      displayName: CM.PublishArtifact
      enabled: ${{ parameters.EnableCMBuild }}
      inputs:
        pathtopublish: '$(Build.ArtifactStagingDirectory)'
        artifactname: MYAPP.CM

The above snippet builds the solution MyApp.Web.sln with the DEV.CM build configuration (typically used for the DEV CM environment) and publishes the artifact with the name MYAPP.CM.

This completes the 2nd post of the Azure DevOps with Sitecore Series which highlights the basics of Pipelines. In the next post, we will dive deep into the pipeline implementation for a Sitecore application.

Cheers!

About me:

Vivek Anandan Venugopalan

Azure DevOps with Sitecore Series: Post 1 – Getting the Azure Repository Setup Right

This is the first part of a series of blog posts in which I will be publishing about my learnings while setting up CI/CD Pipelines for a Sitecore Implementation in Azure DevOps which uses Sitecore Team Development for Sitecore (TDS).

This blog post explains the initial step of Migrating to Azure Repository(GIT) and getting the git setup done correctly.

The Use Cases:

1. Repository Migration:

Migrate the code repository from the Team Foundation Server (TFS) to the Azure Git Repository

2. CI/CD Tool Migration:

Migrate the CI/CD Pipelines Implementation from TeamCity to Azure DevOps Pipelines with YAML Pipelines for Builds (CI) and Classic Pipelines for Release (CD).

3. Team Development for Sitecore (TDS):

The Azure DevOps Pipelines should also include a step to build and deploy the Team Development for Sitecore (TDS) projects in the solution.

This use case is going to be the source for all the blog posts in this Azure DevOps series.

The Repository Migration:

If you have the current source control systems in Git or Team Foundation Version Control (TFVC), you may import the repository directly into Azure Repositories using the out-of-the-box Import Repository option. The GIT import is pretty straightforward but the TFVC migration may be a little tricky and require additional steps. Check out this document for the TFVC Migration to Azure DevOps Repository: Import and migrate repositories from TFVC to Git

The Migration from Team Foundation Server (TFS) to Azure Repository:

You may use the git-tfs library to convert a TFS repository into a git repo and then push the git repository to the Azure Repository. This is a very helpful tool that allows you to import the historical commits as well. Please note that this project is not actively maintained and hence you may face some issues during the transition.

The Manual Way:

You may also manually create a new repository and dump the files which seems like the easiest approach for a non-GIT repository but the only issue is you would lose all the history of commits made on the existing repository.

Note: It is not mandatory to migrate to Azure Repository and you may use other Supported Source Control Systems as the source for the pipelines too.

The GIT Transition

At this stage, let us assume that your codebase has been migrated to Azure DevOps Repository and you have cloned the solution on the local disk. The following steps have to be performed next:

1. Add the .gitignore file:

Adding a .gitignore file should be the initial step when moving from a non-git repository to a git repository. For those of you who don’t know, a gitignore file is similar to the .tfignore file in TFS and is used to specify the files/folders that are to be excluded from committing.

*Fig: GIT works exactly like Ron Swanson*

The following is a sample .gitignore file that can be used for a general Sitecore project. Customize this file according to your needs:

################################################################################
# This .gitignore file was automatically created by Microsoft(R) Visual Studio.
################################################################################

#The .gitignore file
/.vs
*/.vs
obj
bin
*.user

Getting the required .gitignore file with the initial commit is quite important because if you miss adding any entry into this file and it gets committed, you would have to delete the files from the repository, commit the changes and add that entry into .gitignore for another commit.

2. Add the .gitattributes file:

This is the most critical activity that is required if you are using Team Development for Sitecore (TDS). If the TDS item files are committed in the repository without this file, you are going to have a horrible time resolving the issue with pending changes.

Here is a sample .gitattributes file that should be committed in your initial commits before any TDS item files are committed.

#The .gitattributes file
# Do not adjust line endings on Sitecore .item files
*.item -text

In case you do not commit this file in the initial commits, you will see all the TDS item files (.item) in the pending changes without any visible change each and every time. Additionally, you may also also see the following error messages while synching or even running the TDS Deployment Step in Azure DevOps:

#Error Messages

Length of field content does not match the content-length attribute. Field name: ..., field id: ...

The input is not a valid Base-64 string

The Significance of .gitattributes (for TDS):

In the above .gitattributes file, you can see that we inform git not to adjust the line endings for the .items meaning the TDS item files.

Line Endings

TDS handles line endings using LF conventions while GIT uses CRLF conventions for line endings. This option of handling line endings for GIT with CRLF is selected when you install GIT for Windows on the machine and it is the default selected option hence most of us don’t bother changing it.

*Fig: The GIT for Windows Installation Option*

If you select the third option, i.e. Checkout as-is, commit as-is, you won’t face the above-mentioned issue on your machine.

Sitecore MVP Corey Smith has an amazing blog post that explains this in detail: Sitecore TDS – Field Content Does Not Match Content-Length

What if I’ve committed the item files without .gitattributes?

We all have been there and there are a couple of ways to resolve this issue:

Delete the Repository and re-import:

This method works if you haven’t done much work on the new Azure DevOps Repository. The steps are:
Delete the Existing Repository -> Make an initial commit of .gitattributes and .gitignore in the existing repository (TFVC or GIT) -> Import the repository
Delete all the .item files and re-sync:

This is a little complicated step where you delete all the item files from the solution and commit the change. Once this is done, commit the .gitattributes file and re-sync all the folders and items with the Sitecore content tree to re-commit the item files.

Do we require .gitattributes if we install git using the Checkout as-is, commit as-is option?

YES, you should still commit the line-ending changes in .gitattributes file. Even if you and your team have consciously installed git with the as-is option, this should be done for a fail-safe mechanism. As it is the default option while installing git, there may be developers who are onboarded in the future or even developers working on multiple projects who may not have selected this option. Hence it is a standard practice to commit .gitattributes even if you have used the as-is option for line endings.

Note: The above .gitattributes implementation is required for Team Development for Sitecore (TDS) implementations only and if you are not using TDS, this step wouldn’t be required.

3. Committing The Nuget.config:

There might be applications in which the Nuget.config may not be a part of the repository where the solution would be using the Nuget.config from the respective machines. If you want to include a NuGet restore step in your build pipeline and the configuration is read from Nuget.config, then you should commit the Nuget.config file to your repository. The nugetConfigPath input parameter in the yml file specifies the path of the nuget.config file. In the below example, the Nuget.config file has been committed in the folder named Source below the root of the repository.

If you wish to learn more about how Nuget.config is read when it is not available in the repository, you may check my previous blog post: Where is my NuGet Configuration?

The sample Nuget restore command in YAML is specified below.

steps:
- task: NuGetCommand@2
  displayName: 'Restore Nuget Packages'
  inputs:
    restoreSolution: Source/MySolution.Web.sln
    nugetConfigPath: Source/NuGet.config
    externalFeedCredentials: 'my-credentials'
    feedsToUse: config

If you complete these steps, you can safely assume that you have successfully migrated to Azure Repositories and start making commits to the newly set up Azure Repository. This completes the first post in this series. See you soon.

About me:

Vivek Anandan Venugopalan

Where is my NuGet Configuration?

NuGet is one of the most convenient tools used in almost every .NET implementation. I use it day in and day out and was still unaware of important basic information related to its configuration.

This post is the result of my own ignorance of this topic hence I found it necessary to share it so that it is helpful to others in the community. I was recently working on an assignment to get our Sitecore application up on a fresh server using a new build agent. The regular pre-requisites and tools were installed on the agent and then we triggered a build. The build failed at the Nuget Restore step and displayed the following error:

##[error]Error: Not found nugetConfigPath
##[error]Packages failed to restore

The above error was self-explanatory in that the pipeline was trying to find the Nuget configuration but unable to locate it.

The Nuget Settings:

The heart of the Nuget configuration lies in the Nuget.config file. This is an important XML file that contains details about the package sources that should be used to install or restore the respective packages used in the project.

Packages sources can be :

Public Sources
Private Sources
Offline Sources from the Disk: eg: Visual Studio Offline Packages

An example of a Nuget.config file is provided below:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json1" protocolVersion="3" />
    <add key="Sitecore Myget" value="https://sitecore.myget.org/F/sc-packages/api/v3/index.json" />
    <add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />
  </packageSources>
</configuration>

My Initial Thoughts:

Every .NET project that I had worked on until this moment had a Nuget.config file committed in the solution folder so I checked the solution folder to see if there were any issues. I did not find the file anywhere in the project. I thought this might be a miss from one of the developers working on the project who may have deleted the Nuget.config in their recent commits. I cleaned the solution and triggered a rebuild from Visual Studio expecting it to throw an error that Nuget had failed to restore but to my surprise, the build succeeded.

This is when I started thinking about the magical thing that was present on my local machine that caused the Nuget packages to restore successfully without a Nuget.config file in the solution.

You don’t require Magic when you know the Basics:

There are three locations where a Nuget.config file may be scoped from and the solution root is only one of them. They are:

Solution
User
Computer

1. Solution:

This is the most commonly used approach where the Nuget.config file is stored at the root level usually at the same level where your solution file is stored. There is an additional sub-scope that the Nuget.config may even be placed inside any folder up to the drive root.

Eg. Solution file located at D:\Project\Source\MySolution.sln and the Nuget.config file being present at D:\Project

It is the best practice to have the configuration file source controlled usually at the solution root. This gives you control over the configuration and allows you to track the changes.

2. User:

In this scope, the Nuget.config is loaded from the AppData folder for the specific user. The exact location is: %AppData%/Nuget/Nuget.config

In the specific case of our application, the Nuget.config was being scoped from this location.

3. Computer:

At the Computer Level, the configuration is scoped from the location: %ProgramFiles(x86)%\NuGet\Config

Now that you know about the possible scoping locations, you may check each of your applications to understand where the Nuget.config file actually being scoped from.

Some Additional Inputs – Moving Away From Nuget:

As we are reading about Nuget, I found it essential to share a significant Sitecore limitation related to Nuget. Whenever Sitecore releases a Hotfix, it does not provide updates to the corresponding Nuget packages. You have to manually copy the DLL files manually from the hotfix package and reference them accordingly. This has prompted multiple Sitecore implementations to move away from Nuget to the old offline package references. It is like returning to Feature Phones in the era of Smart Phones.

Sitecore should take this feedback and improve on this front. If you would like to read more related to this topic, you may check my previous post: Installing a Sitecore Hotfix: Understand the Sitecore Public NuGet Feeds Limitations

This completes the post sharing a piece of important basic knowledge regarding the Nuget configuration. See you soon in the next blog post.

About me:

Vivek Anandan Venugopalan

Solr Index Rebuilds Taking a Longer Time? Try these solutions

This blog post addresses the issue of Solr Index Rebuilds taking a longer time to complete and suggests some of the solutions to mitigate it.

The Issue:

When you run the index rebuilds, it takes more time than the average time and there might be some issues with your configuration or fine-tuning.

Understanding the basics behind Sitecore Indexing:

Sitecore by default uses 3 threads to index data with all of the indexing jobs sharing these three threads. Any of the indexing jobs irrespective of any index depend on these three threads for their updates. If there are issues with threads like all are occupied or unavailable, the jobs wait for the threads to be free for their turns to run hence taking up a longer time. This limit (of 3) is specified in the configuration setting ContentSearch.ParallelIndexing.MaxThreadLimit in the Sitecore.ContentSearch.config file.

The Solutions:

The following solutions may be tried to check the improvements in Index Rebuild duration. These are Sitecore-suggested changes but do not guarantee an instant improvement and you may still might have to experiment to an extent to get the best out of them.

1. Fine-tune the MaxThreadLimit setting:

Try and increase the value of the setting ContentSearch.ParallelIndexing.MaxThreadLimit setting. As the default value for this setting set by Sitecore is 3, try to increase it to 6 and monitor the results. The higher value of the setting will allow the use of more threads to perform indexing.
One thing to note is that A/B testing becomes very critical here.

Please note that there is a trade-off in increasing this setting as it is going to increase the CPU Utilization of the CM Server and you need to be careful and monitor the CPU Utilization regularly while trying this option. If you have the appropriate hardware resources on the CM server, this change is going to give you a significant improvement.

2. Checking the Index Update Strategies:

The index update strategies play a vital role in the index performance. There is no single best strategy as no one size fits all. It varies for each implementation and is a continuous process to identify the best indexing strategy that is optimum for your implementation. Sometimes out-of-the-box indexing strategies provided by Sitecore might not be enough for your implementation and you may be required to create a custom tailor-made indexing strategy. If you haven’t found the best strategy for your application yet, try to experiment with the different available strategies and decide the best.
The following Sitecore resource provides some good information about the Indexing Strategies on this page: Sitecore Index Update Strategies

Quick Tip: If you are currently using the ‘syncMaster’ strategy for the master indexes (e.g. sitecore_master_index, sitecore_testing_index, sitecore_fxm_master_index and sitecore_marketing_asset_index_master), it would be worth reviewing it if it this strategy is absolutely required. Synchronous strategies are the most expensive in terms of CPU and I/O utilization. The synchronous strategy should be used smartly and only if the index update is time-critical and you require the data in the indexes in real time. You may try switching to intervalAsyncMaster and perform an A/B test to monitor the performance improvements.

3. Limiting Index Update Strategies:

You might sometimes concentrate so much on adding optimization strategies overkilling the entire process. Limit the number of index update strategies to 3 and do not have more than 3 index update strategies per index.

*Fig: Too much of anything is good for nothing!*

4. Switch Solr Indexes:

This is not a strategy to reduce the index rebuild time but a way to keep your index availability to a maximum period and reduce the downtime. This impacts your indexing process as the downtime is significantly reduced as you switch the indexes only when the rebuilding has been completed and the indexes are available to the application even during the period of the index rebuild process.

More information on this topic is available at the following link: Switch Solr Indexes

*Fig: EVERYTHING IS PLANNED (Meme Context: Bollywood Movie Ajnabee)*

This completes the blog post suggesting some approaches to speed up the indexing process. See you soon.

About me:

Vivek Anandan Venugopalan

Addressing the Duplicate Helix (Layer) Folders in the Sitecore Content Tree issue after a Sitecore Upgrade

This blog post focuses on the issue of having duplicate Helix Layers folders namely Foundation, Feature and Project in the Templates, Renderings, Layouts and other sections of the Sitecore Content Tree usually after a Sitecore Update.

The Cause:

This issue arises if you used the Helix structure in your application before the vanilla Sitecore instance started supporting Helix.

Why should you resolve this issue?

I have seen multiple Sitecore implementations having these duplicate folders and not worrying about resolving this issue. This may not cause a direct problem to the day-to-day working of your Sitecore application but has indirect implications. You should fix this immediately because:

1. Not the best practice:

It is a bad practice to have folders with the same name at the same level and Sitecore discourages you from doing so. You will see the following error when you try add items with the same name at the same level:

The item name "{Duplicate Folder Name}" is already defined on this level.

In fact, while performing the Sitecore upgrade, you may have encountered this error and would have set the value of the configuration parameter AllowDuplicateItemNamesOnSameLevel to True to get things to work. This setting is introduced from Sitecore Version 9.3.

A major technical debt is that new developers or even existing developers may get confused and create items in the incorrect folders due to duplicate names.

*Fig: Do not ignore the coding best practices*

2. TDS (Team Development for Sitecore) Synchronization Error:

When you create a new folder below the Feature/Foundation/Project folders in the Sitecore Content Tree for Templates, Renderings or Layouts and try to sync them through TDS, you receive the following error:

Duplicate item named 'Feature' found for item '/sitecore/layout/Renderings/Feature'. Duplicate item names are not currently supported by Sitecore TDS

The first thing that you may have tried after getting this error is to delete the vanilla Sitecore helix layer folders.

*Fig: Let us delete the Vanilla Sitecore Helix Folder*

Deleting wouldn’t help as it throws the following error:

Some of selected items are in resources and cannot be deleted.

These folders would not and should not be deleted.

The Solution:

Two primary straightforward solutions can be used to resolve this issue:

1. Create a parent folder and move your custom helix layer folders below this location:

The best resolution to this issue is to create a parent folder and move the custom helix layer folders below this folder. Think carefully and come up with a valid name for the parent folder as it should not cause issues for multisite implementation as you would reuse components across sites.

Generally, the name of this parent folder is based on the company name or the client name.

This approach is going to help in providing a clear separation between the Sitecore Out Of the Box folders and the custom items/folders created for your project.

*Fig: The structure after custom moving the items to a parent folder*

2. Move the subitems of your custom helix folders below the Vanilla Sitecore Helix Layer Folders:

You may move the subitems of your custom helix layer folders below the vanilla Sitecore helix layer folders and delete your helix layer folders.

This completes this post on handling the duplicate helix layer folders. See you soon!

About me:

Vivek Anandan Venugopalan

Sitecore Moving From MyGet To Nuget For Public Feeds

It was a harrowing time for some Sitecore implementation projects that were performing a CI/CD deployment since 25th July 2023. The official package manager for Sitecore Public Feeds MyGet is facing a total outage and it had a huge impact on the applications dependent on it.

Which implementations/projects have the issue?

If you are using the Sitecore Public Nuget Feeds from MyGet, you may have this issue.

Additionally, this issue would pop up only when you perform the action to restore the Nuget packages. If your CI/CD pipeline or your build process has a step to Restore Nuget Packages (with MyGet as the package source), then it is an alarming situation and has to be resolved as soon as possible.

The Error Message:

NuGet Package restore failed for project ____: Unable to find version '___' of package '___'.
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package '___' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
  https://sitecore.myget.org/F/sc-packages/api/v3/index.json: Unable to load the service index for source https://sitecore.myget.org/F/sc-packages/api/v3/index.json.
  An error occurred while sending the request.
  The remote name could not be resolved: 'sitecore.myget.org'. Please see Error List window for detailed warnings and errors.

How long are the MyGet Feeds down:

The feeds have been down since 25th July 2023 and weren’t up until drafting this blog post on 27th July 2023. This outage now continues for more than 40 hours which is a very long period. You may check the live status of MyGet feeds using the following link: MyGet Feeds Current Status

Quick Actioning From Sitecore:

Sitecore has come to our quick rescue and has published the public feeds on Nuget org. You may use the latest Sitecore Official Public Feed URL as given below:

https://nuget.sitecore.com/resources/v3/index.json

After adding this new package source to your solution or modifying the CI/CD Restore Nuget Package step to fetch the packages from the above URL, all the packages should be restored successfully.

Kindly note that the packages for Sitecore Content Hub, Sitecore Experience Commerce (other than Sitecore XC 10.3), Content Hub, Sitecore PowerShell and Sitecore Installation Framework are not yet available (Uptil 27th July 2023). As SIF packages are also not available at Nuget, new Sitecore installations might also fail.

Keep checking the below article to see if the packages for the above products are available:

https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1002999

How to resolve this issue for Sitecore Experience Commerce and other products which do not have the new feeds available?

As a temporary fix, simply disable the step to Restore Nuget Packages in your CI/CD pipeline or the Build Operation whichever is applicable. If you have a build step that deletes all the packages before starting the process, you would have to disable it too.

Once the updated feeds are available for these products, you can edit the package sources and re-enable these steps.

I am using the Sitecore Public MyGet Feeds but I don’t have a step in the CI/CD Pipeline or in the build process to restore the Packages. Should I worry?

You don’t have to worry immediately but you have to mandatorily update the source of your Sitecore Public Feeds before 1st December 2023 to avoid any disruptions. Sitecore is officially transitioning from MyGet to NuGet for the public feeds and the MyGet Sitecore Feeds will not be available beyond this date.

*Fig: Act now and don’t wait for the deadline*

To sum it up, Sitecore has been looking to move away from MyGet for the public feeds and this outage has prompted an early transition. This is a good move considering the reliability of NuGet over MyGet,

See you soon in another blog post.

About me:

Vivek Anandan Venugopalan

Installing a Sitecore Hotfix: Understand the Sitecore Public NuGet Feeds Limitations

It has been a period of multiple Sitecore Hotfixes where Sitecore has released 3 hotfix packages within a short span of 3 months. Out of these, two have been cumulative hotfixes while one was a non-cumulative one. These hotfixes are listed below:

Security Bulletin SC2023-001-568150
Security Bulletin SC2023-002-576660
Security Bulletin SC2023-003-587441

In this blog post, I am addressing the Sitecore Nuget Public Feed Limitations for Sitecore Hotfixes along with some basics of hotfix packages.

What is a Sitecore Hotfix Package?

Sitecore releases hotfixes for:

Fixing Security Vulnerabilities
Fixing Issues
Minor Improvements
Introducing New Features
Optimizations

These hotfixes are published from time to time without any fixed schedule and you may track these via the articles published under Security Bulletins and Known Issues in the Knowledge Base Portal. Subscribing to these updates on the Knowledge Base portal is an unsaid rule for every Sitecore developer.

The below article gives an overview of how to subscribe to these updates:
How to subscribe to security updates on the Sitecore Knowledge Base

What can be the contents of these Hotfix Packages:

These hotfixes can sometimes be as simple as modifying a parameter in a config file or as complex as a big chunk of files that contains DLLs, Configs, Views, CSS, JavaScript, etc. The focus of this blog post would be on the Sitecore-supplied updated Binary Files (.dll) in the hotfix packages.

What is a Cumulative Hotfix:

A Cumulative Hotfix is a package that contains the fixes of all the other individual hotfix packages released for that particular Sitecore version to date. By applying the latest cumulative hotfix you ensure you do not lose any fixes that have been installed previously.

*Fig: Cumulative Hotfix explained in a single image*

Addressing The Elephant In the Room:

Let us take an example of the latest hotfix package published on 20th June 2023: Security Bulletin SC2023-003-587441.
We will use the Cumulative hotfix for Sitecore XP 10.2 which can be downloaded from this link.
This package consists of multiple DLL files and one among them is the Sitecore.Kernel.dll.

The limitation addressed in this blog post is applicable only if you are using the Sitecore Published Public Nuget Feed references in your project.

When we open a .NET solution built for Sitecore 10.2 in Visual Studio and check the NuGet reference for Sitecore.Kernel package, we will have a 10.2.0 reference as shown in the below image.

Check the file version for this binary file through File Properties.

Now check the file version of the Sitecore.Kernel.dll file which was supplied with the hotfix package Security Bulletin SC2023-003-587441 present at:
\Sitecore 10.2.1 rev. 009331 (CUMULATIVE DELTA WDP XP0 packages).zip\Sitecore 10.2.1 rev. 009331 PRE (OnPrem)_single.cumulative.delta.scwdp.zip\Content\Website\bin

The Sitecore.Kernel 10.2.0 binary file from Nuget package has the file version 17.0.36.0 while the same file from the Hotfix package is of version 17.0.44.0. This difference confirms that you would have to update the Sitecore.Kernel package. When you check the Nuget feed for updates, you would be surprised to know that there is no update available.

If you raise a Sitecore Support Ticket for this issue, you would get a response that:
“Sitecore currently has no plan for distributing hotfixes in this way (Sitecore Nuget Package updates way).“

This is also mentioned in the documentation: Sitecore public NuGet feed FAQ

So the bottom line is:

If you are using Sitecore Public Nuget Feed for package references in your project and if some of these packages are updated in any of the hotfixes released by Sitecore, you won’t be able to update these packages via Nuget as Sitecore has no plans to publish the updated packages that are included in the hotfixes.

The Solutions:

The following solutions may be used to mitigate this limitation:

1. Remove all Sitecore Public Nuget Feed References and add manual file references for all the DLL files.

You would decouple all the Sitecore Public Nuget Feed references from the solution and place the DLL files manually on the disk which would be committed to Source Control and the corresponding references would be added to the projects.

The Caveats:

More efforts are required for removing the Nuget reference and adding manual binary file references
You would be changing the Architecture of the Project which is a big step and may require discussions with multiple development teams and other stakeholders.

2. Create a Private Nuget Feed for all the packages and reference them in the projects:

This is another approach where you decouple your solution from the Sitecore Public Nuget Feeds but rather than storing the binary files manually on your disk, you reference them from private NuGet Feeds where you expose all the packages.

The Caveat:

Added overhead of maintaining the private NuGet feeds

3. The Hybrid Approach – Keep the other Sitecore Public Nuget Feed references as is and just modify the references for the updated DLLs:

In this approach, you would decouple only the references of the updated Sitecore DLLs from Sitecore Public Nuget Feed and re-reference them using either of the above two approaches (Manual File references or Private Nuget Feeds). This is a Hybrid Approach as some Sitecore DLLs are referenced from the Sitecore Public Nuget Feeds while the updated DLLs are referenced either manually or through private NuGet feeds depending upon your approach.

The Caveat:

Not one of the Best Coding Practices
This may lead to confusion as the references are hybrid.

*Fig: The Hybrid Setup would look like* this

4. Replace only the updated DLL Files in the Nuget package source folder:

You would replace only the updated dll files provided in the hotfix package at the Nuget package output location. You do not remove any Nuget references. I wouldn’t recommend this approach unless you are completely sure that the caveats listed below do not bother your application. This approach can be called ‘The Indian Jugaad‘ and may be used in the following scenarios:

There is no step in the CI/CD pipeline for Restore Nuget Packages
The Nuget package DLL files are committed in your source control system and the developers never use the Restore Nuget Packages operation.

The process to be followed during Sitecore Upgrades (for the 4th approach):

Whenever you upgrade Sitecore, update the NuGet packages according to the target version and commit the respective DLL files in Source Control.

The Caveats:

Not one of the Best Coding Practices
This may lead to confusion for developers who mistakenly restore NuGet packages for solution

As you can see, all the above approaches have some Caveats and it is for your team to get together and decide on an approach whose Caveat affects your application the least.

Important Note to Sitecore Technical Architects:

Sitecore Technical Architects must consider this important limitation regarding the availability of Sitecore Public Nuget Feeds while architecting the solution at the initial stages of application development itself and devise the best approach for package references. In this way, you won’t end up changing the architecture midway when Sitecore Hotfixes are published.

Move to SAAS:

One of the main selling points of the Sitecore SAAS product (XM Cloud) is that you don’t have to worry about Sitecore Hotfixes and Upgrades. This can be one of the supporting points to be added when the business is requesting your inputs on moving from the traditional Sitecore Experience Platform to Sitecore XM Cloud.

Suggestion To Sitecore:

Sitecore Hotfixes should be available as a minor update version in the Sitecore Public Nuget Feeds.

This completes the overview of an important limitation of Sitecore Public Nuget Feeds. See you soon in another blog post!

About me:

Vivek Anandan Venugopalan

Webhooks in Sitecore – The Basics Explained

As Sitecore 10.3 is officially available since December 2022, you might have noticed one feature everyone is excited about which is called Webhooks. This blog post gives a basic overview of Webhooks and its support in Sitecore.

What is a Webhook?

A webhook is an HTTP-based function that allows lightweight, event-driven communication between two applications. The most common use case for webhook in Sitecore would be to trigger an email to the content author when a Sitecore item is deleted.

Did that sound like an API?

If it did sound to you like an API, then you are on the right path. For simplicity, Webhooks may be considered as readymade APIs that are used to send small pieces of data when some pre-defined events occur.

Explain Webhook to me like I’m a Millenial

You are very excited to purchase a limited edition Sneakers which is currently out of stock. You go to the sneakers website every 10 mins to check if the sneaker is back in stock. This is a very tiring process and you waste a lot of time on it.

What if the sneaker company notified you as soon as the sneakers are back in stock? Wouldn’t that be cool? This is what Webhooks can do and this is the reason why Webhooks are also so cool.

API Polling:

It is essential to understand the concept of Polling when you want to learn about webhooks as Webhooks were invented to address the shortcomings of Polling.

Polling is the process of repeatedly sending requests to the same endpoint and comparing subsequent responses you receive to determine if there is updated information

Explain Polling to me like I’m a Millenial

In the previous example of purchasing a limited edition sneaker, while you were continuously visiting the website to check if the product is back in stock, you did manual polling. When the same operation is done by a program or an API, it is called API Polling.

Difference between API and Webhooks

Characteristic	API	Webhook
Working	APIs work on request-based output mechanisms.	Webhooks work on event-based output mechanisms.
Way of Operation	For an API to work, there has to be a compulsory request from the Client to the server.	In Webhooks, no request is sent from the client to the server and rather the server sends payload data to the client when a specific event occurs.
Responsibility of Communication	In most cases, the responsibility of communication lies with the client.	Webhooks are often referred to as reverse APIs because they put the responsibility of communication on the server, rather than the client.

Fig: Difference between API and Webhooks

Some use cases where we can use Webhooks in Sitecore:

Notifying the stakeholders when item publishing has failed
Notifying the stakeholders when an item is submitted for approval
Perform a Third-Party Validation on items:
Perform third-party spell checks on an item field and reject the item in workflow if the validation fails.

You can achieve all of these functionalities without writing a single line of code without customizing anything in Sitecore.

The Webhook Payload:

A webhook payload usually consists of a lightweight message about the event in JSON or XML format.

{
  "ActionID": "0a6f3cde-edd3-445c-90c3-08d0783e60a3",
  "ActionName": "Sample webhook submit action",
  "Comments": [
    {
      "Key": "Comments",
      "Value": "Approved!"
    }
  ],
  "DataItem": {
    "Language": "en",
    "Version": 1,
    "Id": "2c8e2214-0d54-4a82-8f84-b60c08f169a9",
    "Name": "Sample item",
    "ParentId": "8fb31904-1bbc-463c-821b-c7c1a87bf13e",
    "TemplateId": "0133f52d-271f-4217-b1cd-04342e3457eb",
    "MasterId": "00000000-0000-0000-0000-000000000000",
    "SharedFields": [
      {
        "Id": "a4f985d9-98b3-4b52-aaaf-4344f6e747c6",
        "Value": "{88AD1387-D4DA-489D-BB4B-45540917E7ED}"
      }
    ],
    "UnversionedFields": [],
    "VersionedFields": [...]
  },
  "Message": "",
  "NextState": null,
  "PreviousState": {
    "DisplayName": "Awaiting approval",
    "FinalState": false,
    "Icon": "Software/16x16/jar.png",
    "StateID": "{87FEC0C1-CAE3-4272-BA58-3DF7082BD1DB}",
    "PreviewPublishingTargets": []
  },
  "UserName": "sitecore\\xmc-e2e-admin@sitecore.com",
  "WorkflowName": "Workflow with webhook",
  "WebhookItemId": "0a6f3cde-edd3-445c-90c3-08d0783e60a3",
  "WebhookItemName": "Sample webhook submit action"
}

Types of Webhooks in Sitecore

There are three types of Webhooks available in Sitecore:

Webhook Event Handler
Webhook Submit Action
Webhook Validation Action

1. Webhook Event Handler:

This is the most commonly used webhook in Sitecore. This webhook is fired on supported events such as item:added, item:deleted, etc. This webhook can be used for notifying other systems about the changes performed on the content.

One of the important use cases that I remember from our previous live project where webhooks would have helped us is listed below:

Privacy Policy: If the Privacy Policy content on a website has been published, a notification would be sent to the Legal Team

***Fig: You can’t get away*** ***when we have Webhooks configured***

Fig: Events currently supported
Source: Sitecore

You must to be very careful while using a webhook on item:saved event as this event can occur multiple times during simple item operations on the UI and as a result, the configured webhook may be fired multiple times.

2. Webhook Submit Action:

The Submit Action Webhook is used to is to notify other systems about workflow state change events. You can send the following details in the payload:

Information about the item in the workflow
Current State of the Workflow
Next State of the Workflow

A simple use case of a Webhook Submit Action in Sitecore would be to notify the Digital Marketing Head when the content for a particular campaign moves to the Approved State after all the stakeholders have approved it in the CMS.

We can add this Webhook to the following elements of a Workflow:

Workflow State:
If you want to fire a Webhook when the item moves to a particular state (as in the above example), attach the Webhook to that workflow state
Workflow Action:
If you want a Webhook to be fired when a particular command has been executed as a part of a Workflow Action, attach the Webhook to that action.

3. Webhook Validation Action:

This is a very important webhook that aids third-party validation of the contents inside Sitecore CMS. The approval of Workflow States in Sitecore can be managed by a third-party application using the validation action webhook. You add this Webhook to a workflow command and when that command is executed, the webhook would be fired and it would expect a response from the third-party application. The item would move to the next workflow state only when the validation by the third-party is successful.

The Webhook Validation Action is different from other two types as this is the only type of webhook that requires a response when the webhook is fired.

A practical use case of the Webhook Validation action is the integration of a third-party spell-check application for validating the text contents of items.

Webhooks Availability:

Webhooks are available with the following Sitecore Products:

Sitecore Experience Platform 10.3 – Webhooks are available even with a Sitecore Experience Manager 10.3 License
Sitecore XM Cloud
Sitecore Content Hub
Sitecore OrderCloud
Sitecore Personalize

Suggestion to Sitecore for Webhooks:

Webhooks should also be available as a separate (.zip) package so that clients on older versions of Sitecore XP and XM do not miss out on this amazing capability. Not everyone is going to upgrade to Sitecore XP/XM 10.3 or XM Cloud sooner. If not free, it can be provided at a nominal cost and the package can be something like SXA which can also be bundled with the Sitecore Installation Package of older Sitecore versions.

***Fig: First World Problems*** ***in a Sitecore World***

This completes a basic overview of Webhooks and its significance in Sitecore applications. See you soon in another blog.

Cheers,
Vivek

About me:

Vivek Anandan Venugopalan

Sitecore Content Hub with 10 questions: Basics Explained

This is the first blog post in the Content Hub series where I try to explain the basics of Sitecore Content Hub by answering 10 questions in each part.

I got a chance to explore Sitecore Content Hub which is one of the hottest Sitecore products in the market currently. This blog would give you a basic understanding of Sitecore Content Hub along with some licensing information. Let us get started:

Q1. What is Sitecore Content Hub?

Sitecore Content Hub is a SAAS (Software As A Service) based product and a one-stop destination for content. SAAS-based means you don’t have to do any manual installation on your machine to get the system setup. Once you’ve purchased the license, you will receive a URL for your Content Hub instance with the corresponding credentials.

Open a browser -> Hit the URL -> Login and can get started with the development.

Content Hub is a one-stop destination for storing content.

Q2. If Content Hub stores Content, is it a Content Management System?

NO. Content Hub is not a Content Management System. Content Hub, as the name suggests, is a Hub for all your content. You integrate Content Hub with your CMS to deliver content on your website. Content Hub and Content Management System work together complementing each other.

***Fig: Content Hub + Sitecore CMS is indeed a Powerful Stack***

Q3. If Content Management System is helping in storing content, why is Content Hub Required?

One of the biggest reasons for investing in Content Hub is the vast amounts of data in organizations and having a versatile single hub for storing the content has become a need of the hour. Small-sized organizations which do not have much data may still manage with a Content Management System without Content Hub.

The following points make it essential to have Content Hub:

Streamline content:
You can streamline content by having a single source of truth for content across various teams.
Omnichannel Delivery:
Content Hub helps in pulling and pushing content from anywhere to everywhere. You can use content from Content Hub in mobile applications, web applications, RSS Feeds, etc. irrespective of the technology and the stack used.
Content Metadata and Relationships:
Content Hub helps in storing large amounts of metadata and establishing relationships between content which helps in establishing better control over the content.
Digital Rights Management:
Content Hub helps control access to copyrighted/licensed material through Digital Rights Management.

Q4. How can we differentiate between Content Hub and a Content Management System?

Multiple teams in your organization may create various content types for a website. This content can be Images, Videos, Excel Sheets, Labels, Plain Text, etc. In most organizations, these contents are stored on the local drives/computers of each team and there is no single source of truth. Content Hub centralizes this approach and stores all the content in one place. You can then use this content from Content Hub in your CMS to display it on the website.

The control of WHERE and HOW the content would be displayed on the website lies with Content Management System while WHAT is displayed (the actual content) is controlled by Content Hub

A Content Management System provides you with the following capabilities that Content Hub doesn’t:

Presentation Control
Renderings
Personalization
Analytics and Reporting

Just for understanding purposes, you may consider Content Hub as the Google Drive for your organization where you store all the content but with a lot more functionalities and capabilities.

Q5. If Content Hub is anyways storing my content at a centralized location, why can’t I use it as a Content Management System?

The answer from a developer’s lens is a YES. You can use Content Hub as it is without a Content Management System to manage content on the websites. The marketing folks would be sad with this answer but this is the reality. When you use Sitecore Content Hub alone without a CMS, you miss out on some of the essential features like:

Presentation Control
Renderings
Personalization
Analytics and Reporting

If your requirement is bare minimum and doesn’t need the above features, you may use Content Hub alone.
We’ve had clients who were only interested in Sitecore Content Hub without the Sitecore Content Management System and the licenses are available for Content Hub alone too.

***Fig: The Disappointed Marketing Folks***

Q6. Can you share a use case where Content Hub can be used without a Content Management System?

Consider a mobile application built in the native Android language. The content for this application like the Images, Videos, Labels and Texts can be stored in Content Hub. This content can then be exposed as Graph QL APIs to the native code using Experience Edge. More information on Experience Edge later but for now, consider Experience Edge as an application that helps to expose the content in Content Hub to any application using APIs.

Q7. Provide a detailed use case where Content Hub is required:

Let us take an example of an eCommerce giant like Amazon. They serve content to audiences across various mediums:

Amazon App: Android and IOS Mobile Application
Amazon Website
Amazon Mobile Website
Social Media
Newsletters
Mobile Push ads
Email Campaigns

It would be a disaster if the contents created for these mediums aren’t located in a centralized repository and this is where Sitecore Content Hub comes into the picture. You can have all the content stored in a single place and have it delivered across these multiple channels, which is also known as Omni-Channel Delivery.

Q8. What are the different Modules that are available with Content Hub?

Content Hub contains five modules:

Digital Asset Management (DAM) with Digital Rights Management (DRM)
Content Marketing Platform (CMP)
Product Content Management (PCM)
Marketing Resource Management (MRM)
Sitecore Content Publisher (Rebranded from Web2Print)

Q9. Explain how the contents are separated in each module?

Understanding what Content in Content Hub means can be a little confusing in the beginning as Content Hub is an umbrella of multiple modules. To put it up simply, I’ve listed what content means to individual modules with examples:

Digital Asset Management (DAM): Assets like Images, Video, PDF Documents, etc.
Content Marketing Platform (CMP): Text Content like Advertisement, Blog, Emails or even a Social Media Message
Product Content Management (PCM): Product Data like Product Title, Product Price, Product Description, etc
Marketing Resource Management (MRM): A planned/ongoing project like a Marketing Campaign

Q10. What are the current licenses of Content Hub and shed some light on some terms like Content Hub Operations and Content Hub DAM

Sitecore Content Hub is the parent “umbrella” product which has all integrated modules together in it. The following licenses are available for Content Hub:

Content Hub DAM License:
Content Hub DAM includes Digital Asset Management (DAM), Digital Rights Management (DRM) and Product Content Management (PCM) capabilities. If you only require the DAM capability of Content Hub, you have to purchase this license which also includes PCM bundled with it.
Content Hub Operations License:
Content Hub Operations is the re-branding of Digital Asset Management (DAM) + Content Marketing Platform (CMP) + Marketing Resource Management (MRM) modules together. When you purchase Content Hub Operations, it means you purchase the entire product with the following modules:
- Digital Asset Management (DAM) + Digital Rights Management (DRM) + Product Content Management (PCM) (Refer to 10.1 to understand why DRM and PCM are included)
- Content Marketing Platform (CMP)
- Marketing Resource Management (MRM)
Content Publisher License:
Web2Print has been rebranded as Content Publisher and is an add-on capability license to the above modules.

***Fig: Content Hub Licensing explained in a single image***

That’s it from this blog which explains the basics of Content Hub. I will see you in the next part with 10 more questions.

Cheers,
Vivek

1. Support for ltsc2022 Windows containers:

2. Create custom languages that are not registered in .NET (en-eu):

3. Compatibility with SQL Server 2022:

4. Implementation of Solr soft commits:

5. XM to XM Cloud Content Migration tool:

6. xDB to CDP Migration Tool:

7. OOTB support for .ico files in the Media Library:

7. [BUG] BlobProviderException thrown when media is detached from an item and the item is published:

Important Update: The Sitecore Downloads page has been migrated:

About me:

Vivek Anandan Venugopalan

What is Continuous Integration (CI):

Artifacts:

What is Continuous Delivery (CD):

Methods to Develop Build and Release Pipelines:

Classic Way of Developing Pipelines or the Classic Pipelines:

The YAML Pipelines:

1. Easier Replication:

2. Maintainability:

3. Code Reviews:

4. Better Versioning:

About me:

Vivek Anandan Venugopalan

The Use Cases:

1. Repository Migration:

2. CI/CD Tool Migration:

3. Team Development for Sitecore (TDS):

The Repository Migration:

The Migration from Team Foundation Server (TFS) to Azure Repository:

The Manual Way:

The GIT Transition

1. Add the .gitignore file:

2. Add the .gitattributes file:

The Significance of .gitattributes (for TDS):

Line Endings

What if I’ve committed the item files without .gitattributes?

Do we require .gitattributes if we install git using the Checkout as-is, commit as-is option?

3. Committing The Nuget.config:

Further Reading:

About me:

Vivek Anandan Venugopalan

The Nuget Settings:

My Initial Thoughts:

You don’t require Magic when you know the Basics:

1. Solution:

2. User:

3. Computer:

Some Additional Inputs – Moving Away From Nuget:

Further Reading:

About me:

Vivek Anandan Venugopalan

The Issue:

Understanding the basics behind Sitecore Indexing:

The Solutions:

1. Fine-tune the MaxThreadLimit setting:

2. Checking the Index Update Strategies:

3. Limiting Index Update Strategies:

4. Switch Solr Indexes:

About me:

Vivek Anandan Venugopalan

The Cause:

Why should you resolve this issue?

1. Not the best practice:

2. TDS (Team Development for Sitecore) Synchronization Error:

The Solution:

1. Create a parent folder and move your custom helix layer folders below this location:

2. Move the subitems of your custom helix folders below the Vanilla Sitecore Helix Layer Folders:

Further Reading:

About me:

Vivek Anandan Venugopalan

Which implementations/projects have the issue?

The Error Message:

How long are the MyGet Feeds down:

Quick Actioning From Sitecore:

How to resolve this issue for Sitecore Experience Commerce and other products which do not have the new feeds available?

I am using the Sitecore Public MyGet Feeds but I don’t have a step in the CI/CD Pipeline or in the build process to restore the Packages. Should I worry?

Further Reading:

About me:

Vivek Anandan Venugopalan

What is a Sitecore Hotfix Package?