Update your configuration to the Coveo for Sitecore 5 initial release

When upgrading from Coveo for Sitecore 4.1 to Coveo for Sitecore 5, you need to make several changes in your Sitecore instance configuration files.

Important

The instructions below pertain to upgrade scenarios 2 and 3 in the Coveo for Sitecore 4 to Coveo for Sitecore 5 upgrade procedure article and assume that you have performed all prior steps in your upgrade scenario.

Manually update the Coveo configuration files

The Coveo configuration files are located in the <SITECORE_INSTANCE_ROOT>\App_Config\Include\Coveo folder. When upgrading, you must compare the changes to the .example files from your current Coveo for Sitecore version with the ones in the build you’re upgrading to. Then, you can merge these changes into your current configuration files. This method lets you keep your own customization intact, while still benefiting from the latest enhancements brought in the product. You can use a merge tool such as WinMerge to accomplish this.

As a result of the feature changes between the October 2018 release of Coveo for Sitecore 4.1 and the November 2018 release of Coveo for Sitecore 5, here are the modifications you must make in the configuration files:

In the Coveo.SearchProvider.config file

  1. The lines below, associated with the AddCoveoFieldsProcessor, have been removed. This processor is no longer required. You may delete these lines in your configuration.

    <!-- The AddCoveoFieldsProcessor adds specific Coveo fields to the search index. -->
    <processor type="Coveo.AbstractLayer.Processors.Indexing.Fields.AddCoveoFieldsProcessor, Coveo.AbstractLayer" />
  2. All of the following lines must be removed from the Coveo.SearchProvider.config file, as they were only valid for on-premises instances of Coveo for Sitecore.

       <!-- The TopResultConfigurationWarningProcessor validates that a Top Result item is correctly configured -->
       <processor type="Coveo.SearchProvider.TopResults.TopResultConfigurationWarningProcessor, Coveo.SearchProviderBase" />
       <cesCommunicationFactory type="Coveo.AbstractLayer.Communication.CES.CESCommunicationFactory, Coveo.AbstractLayer">
         <cesCommunicationConfiguration type="Coveo.AbstractLayer.Communication.CES.CesCommunicationConfiguration, Coveo.AbstractLayer" />
       </cesCommunicationFactory>
       <!-- Coveo AdminService configuration -->
       <adminServiceConfiguration type="Coveo.Framework.Configuration.AdminServiceConfiguration, Coveo.Framework">
         <adminServiceUri>http://localhost/AdminService</adminServiceUri>
         <cesMasterInformation type="Coveo.Framework.Configuration.CesMasterInformation, Coveo.Framework">
           <cesConfigurationPath>C:\CES7\</cesConfigurationPath>
           <id>default</id>
           <acceptedConnections hint="list:AddAcceptedConnection">
             <cesAcceptedConnection type="Coveo.Framework.Configuration.CesAcceptedConnection, Coveo.Framework">
               <connectionComponent>ADMIN</connectionComponent>
               <connectionPort>52800</connectionPort>
               <connectionType>CMF</connectionType>
             </cesAcceptedConnection>
             <cesAcceptedConnection type="Coveo.Framework.Configuration.CesAcceptedConnection, Coveo.Framework">
               <connectionComponent>ADMIN</connectionComponent>
               <connectionPort>52810</connectionPort>
               <connectionType>HTTPS</connectionType>
             </cesAcceptedConnection>
           </acceptedConnections>
         </cesMasterInformation>
         <!-- The username element specifies the username used to connect to the AdminService. -->
         <username></username>
         <!-- The password element specifies the password used to connect to the AdminService. -->
         <password></password>
       </adminServiceConfiguration>
       <!-- Coveo search configuration -->
       <searchCertificatePath>C:\CES7\Config\Certificates\cert-iis.p12</searchCertificatePath>
       <searchServiceUri>https://localhost:52810/7.0/CoveoSearchService</searchServiceUri>
       <queueUri>amqp://localhost:5682/</queueUri>
       <queueUsername>guest</queueUsername>
       <encryptDataOnQueue>false</encryptDataOnQueue>
       <setting name="Coveo.TopResults.FolderPath" value="/sitecore/system/Modules/Coveo/Top Results" />
       <scheduling>
          <agent role:require="!ContentDelivery" name="CoveoSynchronizeTopResults" type="Coveo.SearchProvider.Agents.SynchronizeTopResults, Coveo.SearchProviderBase" method="Run" interval="00:01:00">
            <DatabasesToSynchronize>master;web</DatabasesToSynchronize>
          </agent>
       </scheduling>
       <skipFirstTimeSetupCheck role:require="ContentDelivery">true</skipFirstTimeSetupCheck>
  3. If your <SITECORE_INSTANCE_ROOT>\App_Config\Include\Coveo folder contains the Coveo.SearchProvider.Fields.Custom.config file, this means Coveo has already recovered the fields that used to be indexed through the AddTemplateFieldsProcessor and they’re now included through the IncludeFieldsFromConfigOnlyProcessor. The AddTemplateFieldsProcessor is therefore no longer required. In turn, the AddTemplateFieldsProcessor invokes the coveoIndexingGetTemplates pipeline. Since the coveoIndexingGetTemplates pipeline will no longer be invoked, it too is no longer required.

    You can therefore remove all of the lines below from your configuration.

    <!-- The AddTemplateFieldsProcessor gets the fields from a list of templates and then adds them to the search index.
         The processor invokes the coveoIndexingGetTemplates pipeline to retrieve the templates. -->
    <processor type="Coveo.AbstractLayer.Processors.Indexing.Fields.AddTemplateFieldsProcessor, Coveo.AbstractLayer" />
    <!-- Coveo pipeline used to retrieve the templates with the fields that should be indexed. -->
    <coveoIndexingGetTemplates>
      <!-- The IncludeTemplatesFromConfigOnlyProcessor adds the included templates to the list. If at least one included template is specified, the processor stops the pipeline. -->
      <processor type="Coveo.AbstractLayer.Processors.Indexing.Templates.IncludeTemplatesFromConfigOnlyProcessor, Coveo.AbstractLayer" />
      <!-- The AddTemplatesForIndexedItems processor scans the items to index and gathers the templates that are being used. -->
      <processor type="Coveo.SearchProvider.Processors.Indexing.Templates.AddTemplatesForIndexedItems, Coveo.SearchProviderBase">
        <ApplyInboundFilter>true</ApplyInboundFilter>
      </processor>
      <!-- The IncludeBaseTemplates processor ensures that all necessary base templates are added for the templates included so far. -->
      <processor type="Coveo.SearchProvider.Processors.Indexing.Templates.IncludeBaseTemplates, Coveo.SearchProviderBase" />
      <!-- The ExcludeTemplatesFromConfigProcessor excludes the templates defined in the ExcludeTemplate element from the template list. -->
      <processor type="Coveo.AbstractLayer.Processors.Indexing.Templates.ExcludeTemplatesFromConfigProcessor, Coveo.AbstractLayer" />
    </coveoIndexingGetTemplates>
    Note

    If your App_Config\Include\Coveo folder does not contain the Coveo.SearchProvider.Fields.Custom.config file, steps will be provided further in the upgrade steps to move away from the traditional inclusion of fields through configuration file settings to the new and simpler method using the Command Center user interface.

  4. The following lines, associated with previously sys-prefixed fields, have been edited and moved from the <externalFields> element to the <fieldNames> element. Apply these changes in your configuration.

    <fieldType fieldName="attachmentparentid" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="author" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="clickableuri" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="collection" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="concepts" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="date" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="filetype" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="indexeddate" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="isattachment" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="language" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="printableuri" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="rowid" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="size" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="source" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="title" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="topparent" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="topparentid" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="transactionid" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="uri" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />
    <fieldType fieldName="urihash" isSourceSpecific="true" settingType="Coveo.Framework.Configuration.FieldConfiguration, Coveo.Framework" />

    Additionally, if you’ve created and are using custom result template .cshtml files, remove all sys prefixes from the field names in those files to ensure that the new field names are referenced, as per the fieldName attribute values above. On the other hand, the default.cshtml result template file should be automatically modified during the upgrade and should therefore not require any modifications on your part.

  5. The ref attribute value of the <indexCommunicationFactory> element has been changed. The element now reads as follows:

    <indexCommunicationFactory ref="coveo/cloudPlatformCommunicationFactory"/>

    Apply this modification in your configuration.

  6. The following block has been removed in relation to the end of support for LINQ queries.

    <!-- Pipeline used to modify the values of the LINQ results while they're mapped. -->
    <coveoMapLinqQueryResult>
      <processor type="Coveo.SearchProvider.Processors.Queries.MapCoveoMetadataProcessor, Coveo.SearchProviderBase" />
    </coveoMapLinqQueryResult>
    <!-- Pipeline used to specify which fields should be returned on LINQ query results. -->
    <coveoQueryFieldPipeline>
      <processor type="Coveo.SearchProvider.Processors.Queries.AddAllFieldsProcessor, Coveo.SearchProviderBase" />
    </coveoQueryFieldPipeline>
  7. In the September 2018 release of Coveo for Sitecore 4.1, the element below appeared as an optional addition in the <settings> element:

    <setting name="Coveo.Indexing.PreferSourceSpecificFields" value="false" />

    Coveo now strongly recommends that you add this <setting name="Coveo.Indexing.PreferSourceSpecificFields" value="false" /> element which reverses the default field hashing behavior. Since Coveo for Sitecore now addresses situations where two fields have identical names but different types and field collisions rarely occur, hashing field names should only be used as a last resort (see the isSourceSpecific parameter in About the Coveo Search Provider configuration file).

  8. To fix an issue with FieldReaderCache, locate the defaultIndexConfiguration/fieldReaders element.

    Within this node, add the following line:

    <param desc="id">coveoFieldReaderMap</param>

In the Coveo.SearchProvider.Custom.config file

Remove the following block.

<scheduling>
  <agent name="CoveoSynchronizeTopResults">
    <patch:delete />
  </agent>
</scheduling>

In the Coveo.SearchProvider.Rest.config file

  1. Locate the following block which is associated with on-premises instances of Coveo for Sitecore.

    <!-- The secret key must be configured in the search api service as well. This way, the search api service can trust the application. -->
    <applicationSecret>replace this with your own application secret</applicationSecret>
    <!-- The timeout period for requests going through the search api proxy.-->

    Replace this block with the line below.

    <!-- The timeout period for requests going through the REST endpoint.-->
  2. Locate the following line which is also associated with on-premises instances of Coveo for Sitecore.

    <searchApiUri>http://localhost:8080</searchApiUri>

    Replace this line with the one below.

    <searchApiUri>https://platform.cloud.coveo.com</searchApiUri>
  3. The following code block has been removed. Apply this modification to your configuration.

    <!-- The "getUserMembers" is exposed by Sitecore2's web service. Therefore, the "getUserMappings" pipeline
         should be used instead to control to which identities a Sitecore user identity is expanded. -->
    <getUserMembers>
      <!-- This processor invokes the "getUserMappings" pipeline to expand a Sitecore user identity.
           Invoking the "getUserMappings" pipeline from here ensures a consistent user expansion between on-premises and Cloud deployments. -->
      <processor type="Coveo.SearchProvider.Rest.Processors.Sitecore2.GetUserMembers.InvokeGetUserMappingsPipeline, Coveo.SearchProvider.Rest" />
    </getUserMembers>
  4. The following code block has been removed. Apply this modification to your configuration.

    <!-- This processor maps Sitecore users to Active Directory users by following a domain mapping. -->
    <!--
    <processor type="Coveo.SearchProvider.Rest.Processors.GetSearchUserIdentities.AddActiveDirectoryIdentity, Coveo.SearchProvider.Rest">
      <domainMappings hint="raw:AddDomainMapping">
        <domainMapping sitecoreDomain="ad" adDomain="acme.corp.com" />
      </domainMappings>
    </processor>
    -->

In the Coveo.UI.Controls.config file

  1. The elements below have been removed, along with all their children, as a result of the end of support for the Legacy Search UI Framework. Apply these modifications to your configuration.

    • <commands>

    • <source mode="on" namespace="Coveo.UI.Controls" assembly="Coveo.UIBase" prefix="coveouilegacy" />

    • <processors>

    • <getChromeData>

    • <inheritsFromCoveoTemplate>

    • <getDataSourceDialogURL>

  2. Locate the following code block.

    <initialize>
       <!-- This processor is required to register the routes for the analytics REST API. If you're not using the analytics
            REST API, you can disable this processor. -->
       <processor patch:before="*[starts-with(@type, 'Sitecore.Mvc.Pipelines.Loader.InitializeRoutes')]" mode="on"
            type="Coveo.UI.PipelineProcessors.Initialize.InitializeCoveoRoutes, Coveo.UI" />
    </initialize>

    Replace this block with the following.

    <initialize>
       <!-- This processor exposes a simple REST endpoint used in the UI components. -->
       <processor patch:before="*[starts-with(@type, 'Sitecore.Mvc.Pipelines.Loader.InitializeRoutes')]" mode="on"
            type="Coveo.UI.Rest.InitializeCoveoRoutes, Coveo.UI.Rest" />
    </initialize>