Pages

24 September, 2024

Sitecore Scheduled Publishing Module - Published 10.4 packages and Docker images

Sitecore Scheduled Publishing module has been updated to support Sitecore 10.4. Following changes were made as part of the release. 

  1. Updated Source to Sitecore 10.4

    Module source has been updated to 10.4. 

  2. Created Packages for Sitecore 10.4

    Two packages were created. One is with IAR files for content and another one is the regular Sitecore content package. 

  3. Created and published Docker Images

    Created and published new Docker image with tag 10.4. This image is built with IAR files. Along with 10.4 tag, latest tag has been updated to 10.4. You can view it here in Docker Hub. 

  4. Documentation updated for schedular configuration

    In order for the scheduled publishing to publish the content, Sitecore's scheduling frequency and interval needs to be adjusted. This has been clearly documented in Readme markdown.
A new release has been added in GitHub with all the relevant assets. https://github.com/nehemiahj/SCScheduledPublishing/releases/tag/Sitecore_10.4

20 September, 2024

Troubleshooting Issues in Sitecore (IIS) - Razl, SPE Content Migrator

This blog post is simply about some basic troublshooting steps whenever we have integration with 3rd party modules which relies on custom APIs in Sitecore. 


First one in this discussion is Sitecore Razl. Sitecore Razl is a database comparison tool for the Sitecore CMS. It allows a developer to compare two different Sitecore databases and see the differences in each. A developer can then migrate changes from one database to the other. (ref)

Once the connection specific package is installed in a server, when trying to load the connection in the Razl tool, it would say it cannot connect. Same accessGuid is present in configuration and Razl Connection window. 

Second one is related to SPE Content Migrator. Script used to migrate content between Sitecore instances using Sitecore PowerShell Extensions.(ref).

In this case, even after enabling SPE Remoting and allowed role "sitecore\PowerShell Extensions Remoting" for authorization, migrator script always responded with the below error. 

Test Script:

Error:


Troubleshooting Steps: 

Both these errors have similar troubleshooting steps. Both these tools interact with Sitecore CM using custom APIs or Handlers. With the current client, there are many IIS rewrite rules added to support their business requirement or for security reasons in Content Management Server. 
  • LowerCaseRule
  • RemoveTrailingSlashRule
  • Root Hit Force HTTPS Redirection
  • Sitecore Login or Admin Force HTTPS Redirection
  • Forbidden
  • Redirect Error Page for a Business Requirement
First step - We enabled IIS logs for the CM site and also enabled all the available fields to log. Refer here to find the list of available fields in IIS Logs - https://www.finalanalytics.com/help/httplogbrowser/field-list.html. We tried multiple times from the tool (Razl or SPE Content Migrator) and we found the POST requests and it was redirected with 301 and a GET request was sent finally to Sitecore. Sitecore was not able to respond to the GET request as it was expecting a POST request from these tools. We tried to check the IIS rewrites one by one and found one of these rewrite rules are redirecting these requests. 

Razl: It was LowerCaseRule which redirected the Razl request. We added the negate rule to avoid Razl URLs. 


SPE Content Migrator: It was RemoveTrailingSlashRule rule which redirected all SPE migrator requests. We added the exception to prevent it. 


It is best to start with IIS first to understand the source of the problem. Happy Troubleshooting!.








18 September, 2024

Coveo for Sitecore - Endpoint Deprecation Issues? Upgrade the Coveo for Sitecore module

Even though we migrated Coveo endpoint to Organization specific endpoint, we still get email from Coveo that deprecated endpoints are being used. Looking at the traffic in Coveo administration, we were still getting much of the analytics traffic using deprecated endpoint. 

Coveo for Sitecore version: 5.0.1277.4 (Release date: October 23, 2023)




The latest Coveo for Sitecore module version (5.0.1368.1) has fixes for updating the analytics endpoint. In the release notes, we have quite a few Analytics related changes and proper analytics endpoints are being used with this version. 

WEB-6836: Fixed the content structure of the Coveo Page View Analytics request payload.
WEB-6922: Removed no longer required usage reporting.
WEB-6937: Fixed the analytics endpoint being used when you bypass the Coveo for Sitecore proxy.
WEB-6954: Simplified the way the Usage Analytics endpoint is composed, depending on the context.

Example: \Coveo\Hive\js\CoveoForSitecore.js


Once the module is upgraded, the traffic starts to drop in the deprecated endpoint and eventually leading to 100% in the recommended endpoint. 

16 September, 2024

Coveo for Sitecore - Clickable URI when content is outside of all Site definitions (Shared or Global Pages)

Coveo for Sitecore generated Clickable URI at the time of indexing, but the site part of the clickable URI is recomputed automatically at query time. What if the content is outside of site definition and how Coveo for Sitecore will resolve Site and generate the Clickable URI - this blog gives an overview of how it is handled in Coveo.

During the indexing time, Coveo for Sitecore will try to resolve the site definition so that URIs can be generated. In the site definition, hostname attribute can have multiple domains or wildcards. If it has multiple values, then targetHostName is mandatory so that Coveo can use it to generate the URIs. 

This is the order by which Coveo for Sitecore will try to resolve the site using ResolveItemSiteProcessor.
  1. First, it will eliminate all non-content sites - coveo_website, coveoanalytics, coveorest, coveoapi, shell, login, admin, service, modules_shell, modules_website, scheduler, system, publisher
  2. It will concatenate rootPath and startItem of each content site definition and compare it with the Item path.
  3. If the language attribute is available in Site definition, then it will be compared with the item language. 
  4. If no site is selected with the previous steps, then it will choose the first site of the remainder content site.
  5. If no site is resolved, then it will use Sitecore Setting 'serverUrl' value if available. 
  6. If no site is selected in any of the steps, then default host of the Sitecore installation will be used. 

In our case, we have Global and Stores content page items which are not part of any of the site definition so the default host of the Sitecore installation was used to generate the URLs. Also, we have requirements where URL should be formatted in certain ways based on business requirements. 

The drawback of these items which do not have site definition is that Coveo for Sitecore will consider these items are simple indexable Sitecore Content Items rather than a page where HTML binary can be generated. When looking at the Content Browser, we can see huge number of Sitecore Items rather than HTML. 


Content Tree Structure:



In Coveo for Sitecore, there are many pipelines through which we can manipulate the content. In this case, the manipulation is required to set the context site and then use the custom ItemUrlBuilder to get the required URLs and it can be sent to index the pages. 

On a higher level, Coveo for Sitecore will run through these pipelines and processors.


For the item which are under a site context, clickableUri's are generated properly and Coveo for Sitecore will be able to send the request, generates the response HTML and send the indexable content to Coveo. For the items which are not under a Sitecore Site context, the default 'website' site definition will be used as the Site context. then the default host of the Sitecore installation will be used. 

If we are using <serverUrl>, we are tied to one URL per Sitecore instance. In case if we have multiple sites in a Sitecore instance, serverUrl concept will be defaulting to only one domain. 

There is a pipeline which helps Coveo for Sitecore to get the Site definition for the current item. Name is  coveoResolveItemSite. In this pipeline, out of the box processor ResolveItemSiteProcessor helps to find the site definition. Since these items are not under a valid site definition, it will resolve to default 'website' site definition. We added another processor in this pipeline to check if these items are Shared pages or the Store pages and then set the site name for the item. 

Processor to Set the Context Site: Site name is hard coded for this blog post.


Config Patch for Processor: 


Once the Context Site is set, the custom ItemUrlBuilder which is used in the website will kick in. That will help in generating the proper URL for these Global items. 

You may face an issue when rendering the results from Coveo. You may need to add custom processor in coveoProcessParsedRestResponse pipeline. You can do it only if the rendered URL in search results page has issues. 



blockquote { margin: 0; } blockquote p { padding: 15px; background: #eee; border-radius: 5px; } blockquote p::before { content: '\201C'; } blockquote p::after { content: '\201D'; }