July 2018 – Unravel Sitecore!

July 27, 2018July 27, 2018

Localization of your search page

Couple weeks ago I was psyched to start a series on our first hand experience dealing with Coveo for Sitecore on a multi-tenant/multi-site Sitecore instance. Check out my first two posts below:

Link Manager Gotcha
Get Your Links right

Now, last, but, not least when you have such huge instance of Sitecore, you are bent to have things you would want to localize due to multiple languages you are supporting. I usually see the solution in two folds.

Coveo OOTB component localization
Custom string localization – Like Facets or any strings on your search listing card that are computed field for instance.

The first one is quite simple and easy to do as Coveo carries responsibility OOTB to load most close culture based on context language. If you go to viewsource on your search page, you will see that Coveo has already done some magic for you. It loads the culture *.js file based on your context language. This happens right the view based on below line of code on Coveo Search View.

<script type="text/javascript" src="/Coveo/js/cultures/@(Model.CultureName).js"></script>

That should take care of your result summary on left top corner above your results. For your sorting components which you may have added using your DateSortView or RelevancySortView, to localize the sorting header such as “Relevancy” or “Date” in context language, Coveo looks for special data attribute on HTML called ‘data-caption’ and if your HTML element for your facet has this attribute loaded with your title and if that is a existing key on locales dictionary object of your interested culture/language then it is respected and corresponding localized string is shown on your page.

Now, for the second fold, if you would like to localize your Facet values, Headers, etc., There are few things to consider/answer – Do you show just one language content on your search page per site? If you are – Life is simple, just ensure you have localized content loaded on your Facet field. If your facet is based on computed field, ensure you are loading language specific value based on currently indexed item language. For your facet header to be localized, you have couple of options here as well, you can either read it from your localized dictionary on Sitecore if you have one, if not, load up your JS localize dictionary with new values as noted in the link below.

https://docs.coveo.com/en/421/javascript-search-framework/changing-the-language-of-your-search-interface

Now, the problem actually happens when you have more than one language content show up on your search page, in that case, you will have an issue with mixed values which obviously is not UX friendly. You can see a good solution and huddle between me and my favorite Sitecore MVP and Coveo champ below(@jflh ). 🙂

https://answers.coveo.com/questions/16338/localize-facet-values-on-multi-site-solution-using.html?childToView=16358#comment-16358

This is the last piece of this series and I am sure there will be more to come, this one is near and dear to my heart and the amount of learning and information I gathered through this Implementation is priceless. Although, Coveo and Sitecore never fail to amaze me, there is more room to learn and grow with these products every single day. 😉

Happy Coveo for sitecore implementation to every one!

Some helpful links:

https://developers.coveo.com/display/public/JsSearch/Localization

https://docs.coveo.com/en/421/javascript-search-framework/changing-the-language-of-your-search-interface

July 25, 2018

Coveo and Sitecore Link Provider

My last post was a kick off a series of things to watch out for and pay attention to while implementing Coveo For Sitecore on a Multi-tenant/Multi-Site Sitecore instance. This is a runner-up for my last post and part of same series. Let me start this by saying, URL on search result is single most important entry point for your user to see detailed content around what they think is relevant. To ensure this is rendered right every single time, It is very critical that you know your Sitecore Link provider or Custom Link provider if any in and out on your Coveo For Sitecore installation.

There are few things that you will need to know in order to fine tune anything or in order to debug issues if any when you see things you do not wish to see in relation to Url’s either on Indexes or on your search page. If you are lucky and do not have much of customization going in your Sitecore link provider, you should be fine doing nothing as Coveo fires off link provider at it’s two most important phases OOTB.

Index Sync Process
Displaying paged results on Coveo driven search page

Now, the most important thing to remember is that while Coveo does #1 noted above it calls Sitecore Link Provider in “shell” context while doing it’s best to load up UrlOptions object that is passed in as a parameter to Sitecore GetItemURL method of Link Provider with appropriate site details it could resolve the currently indexed item with. Coveo has their algorithm that runs as part of ResolveItemSiteProcessor located in coveoResolveItemSite pipeline. Below is the snippet of that processor located on Coveo.SearchProvider.Config

<coveoResolveItemSite>
<processor type="Coveo.SearchProvider.Processors.ResolveItemSiteProcessor, Coveo.SearchProviderBase" />
</coveoResolveItemSite>

If this processor is not working wonders for you, go ahead and remove this in your favorite custom coveo configuration file and add your own. For curious brains, I recommend changing your level of logging to DEBUG to understand what happens step by step while Coveo tries syncing your Index. That was very insightful in understanding sequence of calls and pipelines that fire while Coveo is indexing or doing sync process. But, do remember change that back to INFO after your appetite is satisfied. 😉

Now, for the last clue, on #2 stated above when your Coveo Search Page renders your search results for a query, it calls Sitecore link provider again to get the click uri for each search result that goes with each search result. Now, pay attention here, very important to know that the context site this call runs in is “coveorest”. If your link provider is super awesome and written very well thought out, you will have no problems regardless on the context site the call is running in. But, if your link provider is using context.site instead of using site info from UrlOptions or doing some thing really out of this world, you have to know these things to ensure you hit the gold.

Hopefully these tidbits will help you debug any issues while Coveo constructs the URL’s at indexing or run time. If you have lot of shared content that does not reside under a specific site node, then, it is very hard to get the URL right at indexing time which is why it is even more important to focus on #2 to ensure the end user experience is seamless and correct leading them to correct site, language and context.

There, I gave away a hint, next up, I will be covering language related insights like fall back and localization in my next post. That is all for now, tune in soon for more. 🙂

July 16, 2018

Implement Coveo on Multi Tenant/Multi Language Architecture

I am very excited to start this series as we are almost close to pulling off Coveo Cloud Implementation on a multi site/multi language Sitecore Instance using legacy Coveo For Sitecore Javascript Framework to support web forms Sitecore Implementation. I am gathering my thoughts around all the challenges we faced while getting Coveo to work seamlessly with complex Sitecore Instance. Some were very straight forward and some were anything but that. 🙂

I am going to list down each important problem and note options to tackle each. Do note that though most of the solutions I would attempt to provide are generic, it highly depends on your Sitecore implementation and customization done to Sitecore in general.

One thing that really helped me solve some of these is understanding when and where Coveo connects with Sitecore. I would recommend to deep dive on this to any one who is attempting to implement Coveo For Sitecore on their multi tenant and multi lingual Sitecore implementation.

I will start by noting the first problem we faced right after Coveo for sitecore installation on our system. On Diagnostics page, we had the error such as noted in question and answer below.

https://answers.coveo.com/questions/15435/coveo-search-rest-endpoint-invalid-uri-the-format.html?childToView=15530#comment-15530

One of the first question to answer when implementing Coveo For Sitecore is – Does your Sitecore implementation have a custom link manager as that drives what you would need to watch out for or customize if needed, a quick way to check would be

-> Go to your /sitecore/admin/showconfig.aspx and examine what you see in the node below. if you see default provider as something other than “sitecore”, then, you can ensure that there has been some customization done on this. To be honest, any medium to high sized Multi tenant instance that has been active on Sitecore for long time would have some customization around it. So, it is even more important to know how to ensure Coveo works with your custom link provider settings.

link provider section on config

For instance, in our case languageembedding setting on Linkprovider was set to “always” which means that any website/site served by Sitecore, when a link is generated it would append language to it. That should surely ring some bells, in Coveo For Sitecore case upon installation of package, you would see three new sites in the <sites> node when you take a peek at showconfig which are named as coveo_website, coveoanalytics, coveorest. We definitely do not want to add language embedding on these URL’s here to ensure we do not throw off internal business logic on Coveo end.

To gracefully solve this, I would recommend having an ability to use different Link Providers per site. There is a very decent solution compiled by my favorite Sitecore MVP Jammy Kam below.

Site Specific Link Provider for Multisite Implementation in Sitecore

By doing this we can assure that Coveo specific sites do not have language embedding in it that would cause issue noted on Q&A above.

Of course, if your sitecore implementation was done more on old school style where the answer was – There is a pipeline for that. 🙂

In those cases, check to see where you can ensure to exclude Coveo sites from having language embedding on them.

One open question I do have is would this be any different with Sitecore 9.0+, a short answer might be a NO. If any one has any input in regards to this, leave a comment.

That is it about our first ever hiccup, more to come soon. My hope is that this series will help any one who is driven to use Coveo for Sitecore components and power of framework on a complex Sitecore instance, but, are worried that it might be quite a feat or they might be safe using total custom system. You can re-visit my blog on this topic and I am sure you will get confidence in sticking to framework instead. 🙂

Tune in for more on this series!