Skip to main content

Sitecore Multisite - Unexpected provider type: System.String. Expected: Sitecore.Links.LinkProvider

Hi Team,

Today's blog post is regarding real live scenario which we came across while having multisite solution in Sitecore headless set up.

Well, We have had couple of deployments but one fine morning after the deployment we started getting below error on our stagging site (UAT)


and in Sitecore logs we were getting same following logs 

Exception: System.InvalidOperationException
Message: Unexpected provider type: System.String. Expected: Sitecore.Links.LinkProvider
Source: Sitecore.Kernel
   at Sitecore.Configuration.DefaultFactory.GetProviders[TProvider,TCollection](List`1 nodes)
   at Sitecore.Configuration.DefaultFactory.GetProviders[TProvider,TCollection](String rootPath, TProvider& defaultProvider)
   at Sitecore.Configuration.ProviderHelper`2.ReadProviders()
   at Sitecore.Configuration.ProviderHelper`2.get_Provider()
   at Sitecore.Links.DefaultLinkManager.ParseRequestUrl(HttpRequest request)
   at Sitecore.Web.RequestUrl.Parse(HttpRequestBase request)
   at Sitecore.Pipelines.HttpRequest.HttpRequestArgs.Initialize()
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain, Boolean failIfNotExists)
   at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain)
   at Sitecore.Web.RequestEventsHandler.OnBeginRequest(HttpContextBase context)
   at Sitecore.Nexus.Web.HttpModule.HttpApplication_BeginRequest(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Troubleshooting & Solution

Our actual set up is, We have

1) One site with headless SXA 
2) One legacy headless site without SXA

and development of both happening in parallel with two different team but deployments are planned in such a way that non SXA site gets deployed first and then the other SXA site on different times.

Now, Above error clearly says that on UAT, it is not able to find the LinkProvider which is configured, and previously it was working, So following was the patch which was applied and went on to both DEV and UAT server, but on DEV it worked fine and on UAT it is failing

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <linkManager>
      <providers>
        <add name="localizedProvider">
          <patch:attribute name="lowercaseUrls">true</patch:attribute>
        </add>
      </providers>
    </linkManager>
    <links>
      <urlBuilder>
        <lowercaseUrls>true</lowercaseUrls>
      </urlBuilder>
    </links>
  </sitecore>
</configuration>

Thanks to my colleague Ajay Gour who reviewed past commits and we figured the patch which went up.

So we looked at the showconfig.aspx of working DEV environment and compared it with above patch and found our that patch is looking for "localizedProvider" which requires SXA to be installed otherwise it will never find that provider and above yellow screen will come and because on DEV both the team are working SXA was installed and hence that patch was working.

Basically, Because of having same Sitecore instance for both the SXA and non SXA site, this patch went up but for this patch to work prerequisites is, SXA should have been installed for this "localizedProvider" to work

So solution to this was either to install SXA dependencies being same sitecore instance or changing the patch to target the default Sitecore link provider and patch it, Because for the site which is non SXA should not have dependencies on provider of SXA site

Because deployments for both sites can took place at different time expecting SXA to be present on Sitecore instance is not valid

so we changed that patch to following

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <linkManager defaultProvider="sitecore">
      <providers>
        <add name="sitecore">
          <patch:attribute name="lowercaseUrls">true</patch:attribute>
        </add>
      </providers>
    </linkManager>
    <links>
      <urlBuilder>
        <lowercaseUrls>true</lowercaseUrls>
      </urlBuilder>
    </links>
  </sitecore>
</configuration>
 
Above patch we made sure that it does not target the localizedProvider because if SXA is not installed, it will not work & for the sites which needs SXA when they go live, we made sure that those sites have "localizedProvider" selected from site settings so it works for both the sites with different link provider. 

Installing SXA is also an option, and keep the patch same, but we did not want SXA dependencies for legacy sites though it will  be one time activity.

Now when the site with SXA will go live, we will revisit and check things for both of them and because SXA site has provider configured in its site setting it should work "as-is"

Thank you for my partner in all these troubleshooting and discussions Kiran Sawant my team member for his help and making sure that changes are propagated to environments and checked.

Comments

Popular posts from this blog

High CPU to completely normal CPU - SXA issue, SXA pages not loading in mobile device

  Hi Team, Today i am going to share one of the nightmarish issue with you all, We are having Sitecore 9.1.1 hosted in azure PaaS environment Our site was working just fine and no noise, but we have been working on a feature release where 7-8 months of development needed to be released to production, Big GO LIVE event right?  Also to make the development smoother we also introduced BLUE/GREEN deployment slots in the same release, so we can easily SWAP slots and go live Everything went well, we went live, we even did load and performance testing on our staging and pre-prod and we were confident enough of results Very next day we started getting "SITE DOWN" alerts, and also product owners and clients mentioned that site is very slow for them in US time and in our morning when we were accessing it, it was working lighting fast so we were clue less at start, but we started digging  1) First thing caught our eyes were HIGH CPU spikes, in US time, also without any traffic CPU used

Every Sitecore Instance using GQL is prone to this scenario of template not found - Sitecore Component With GQL Queries Broke On Production

Hello Team, Today, I wanted to share a real scenario and a solution of it about what happened  suddenly to our components and how we identified it and how we resolved it, and most importantly it could happen to your installations too Scenario We have one Sitecore 10.2 headless instance and two sites, One site is non-sxa which is legacy site and another site is a new site which uses headless SXA. Now, non-sxa site is already live and working fine with all components etc. and the new headless site was in development and it has separate development team, So we have same DEV/UAT/PROD environments. One fine morning they took their code and site on environment but strangely some of the GQL components like header footer of legacy site disappeared.  Troubleshooting Steps 1) We checked the broken component's GQL query  2) We took that query and fired it in GQL IDE, and we observed that, Some of the templates references we used were not found, which was working just fine and we have not had

An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

You have noticed many times that everything was working fine and suddenly the below error starts coming and you find no way to work it out An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. The reason for this is the receiving size of WCF service is smaller then the data which is coming from service It was working before because it was small,So you will have to try to increase the receiving setting in your end point,Possible settings can be following maxStringContentLength="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxArrayLength="2147483647" That would definately help you!!!