Blog posts by dada

Blog posts by dada2025-09-29T12:10:42.0000000Zhttps://world.optimizely.com/blogs/dada/ Optimizely World Trigger DXP Warmup Locally to Catch Bugs & Performance Issues EarlyHere’s our documentation on warmup in DXP: 🔗 <a href="https://docs.developers.optimizely.com/digital-experience-platform/docs/warming-up-sites">https://docs.developers.optimizely.com/digital-experience-platform/docs/warming-up-sites</a> What I didn’t know is that you can also trigger warmup in your local development environment. This can help expose bugs or issues before deploying to DXP and INT/PREP/PROD. Example: <pre class="language-csharp"><code>if (_webHostingEnvironment.IsDevelopment()) { services.AddCmsWarmup(configure => { configure.Disable = false; configure.FollowLinkLevel = 10; // Should cover most pages? configure.WaitingForStartupTimeout = TimeSpan.FromSeconds(180); configure.StartupWaitingInterval = TimeSpan.FromMilliseconds(10); configure.RequestTimeout = TimeSpan.FromMinutes(1); configure.MaxNumberParallelRequests = 10; // Increase to speed up warmup and simulate more load configure.AdditionalPaths.Add("/en/alloy-plan"); // Add path to warmup that crawling won't find following links }); ...</code></pre> Note: .AddCmsWarmup() is already implicitly triggered when using .AddCloudPlatformSupport(). However, for reasons I won’t go into here, it’s not something you trigger in your local/development environment.  2025-09-29T12:10:42.0000000Z

Blog post

Make Global Assets Site- and Language-Aware at Indexing TimeI had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This code is provided as-is but please let me know if you have any feedback. In Episerver (Optimizely) CMS, global assets—such as images, documents, and blocks stored in the Global Assets folder—are not tied to a specific site or language.  Yet, the content that references typically is. You might have noticed a common issue: When implementing a search on Site A, assets referenced only by content on Site B still appear in the results and vice versa. That’s maybe not what we want . Let’s say you have: <ul> <li> Assets used exclusively on Site A, or </li> <li> Assets shared between Site A and Site B. </li> </ul> When a user searches on Site A, you want results that are relevant only to that site—including global assets referenced by that site’s content. Likewise, if an asset is shared between both sites, it should appear in both result sets. To support this, your indexing process must make global assets aware of which sites and languages reference them. <h2>This Is the Way</h2> If you're using UnifiedSearch, this filtering on Site ID and language typically works out of the box via: * FilterOnCurrentSite() / FilterOnSite() * FilterForVisitor() / PublishedInLanguage() And for typed searches, you can easily apply these filters yourself. <h2>Update the Initialization Module</h2> To get this working for global assets, we override the default indexing behavior for SiteId() and PublishedInLanguage() by excluding the built-in fields and replacing them with our own logic. <pre class="language-csharp"><code>SearchClient.Instance.Conventions.ForInstancesOf<IContentMedia>().ExcludeField(x => x.SiteId()); SearchClient.Instance.Conventions.ForInstancesOf<IContentMedia>().IncludeField(x => x.SiteId(true)); SearchClient.Instance.Conventions.ForInstancesOf<IContentMedia>().ExcludeField(x => x.PublishedInLanguage()); SearchClient.Instance.Conventions.ForInstancesOf<IContentMedia>().IncludeField(x => x.PublishedInLanguage(true));</code></pre> <h2>Extension Methods</h2> We define custom logic in a static class to determine which sites and languages reference a given global asset.  <pre class="language-csharp"><code>using EPiServer.Find.Cms; using EPiServer.Framework.Cache; using EPiServer.ServiceLocation; using EPiServer.Web; using EPiServer.Find.Helpers; public static class GlobalAssetsExtensions { private static readonly Lazy<ISiteDefinitionResolver> _siteDefinitionResolver = new(() => ServiceLocator.Current.GetInstance<ISiteDefinitionResolver>()); private static readonly Lazy<IContentLoader> _contentLoader = new(() => ServiceLocator.Current.GetInstance<IContentLoader>()); private static readonly Lazy<IContentRepository> _contentRepository = new(() => ServiceLocator.Current.GetInstance<IContentRepository>()); private static readonly Lazy<IContentVersionRepository> _versionContentRepository = new(() => ServiceLocator.Current.GetInstance<IContentVersionRepository>()); private static readonly Lazy<IObjectInstanceCache> _objectCache = new(() => ServiceLocator.Current.GetInstance<IObjectInstanceCache>()); private static readonly Lazy<IContentCacheKeyCreator> _contentCacheKeyCreator = new(() => ServiceLocator.Current.GetInstance<IContentCacheKeyCreator>()); public static IEnumerable<string> SiteId(this IContentMedia content, bool foobar) { content.ValidateNotNullArgument(nameof(content)); var siteDefinitionResolver = _siteDefinitionResolver.Value; var contentLoader = _contentLoader.Value; var contentRepository = _contentRepository.Value; var objectCache = _objectCache.Value; var contentCacheKeyCreator = _contentCacheKeyCreator.Value; if (siteDefinitionResolver.GetByContent(content.ContentLink, false) == null) { if (ContentReference.IsNullOrEmpty(content.ParentLink) || !contentLoader.TryGet<IContent>(content.ParentLink, out _)) { return Enumerable.Empty<string>(); } if (contentLoader.GetAncestors(content.ContentLink) .Any(x => x.ContentLink == ContentReference.GlobalBlockFolder)) { var cacheKey = $"SiteIds:{content.ContentLink.ID}"; var cachedSiteIds = objectCache.Get(cacheKey) as IEnumerable<string>; if (cachedSiteIds != null) { return cachedSiteIds; } var contentRefs = new HashSet<ContentReference>(); foreach (var link in contentRepository.GetReferencesToContent(content.ContentLink, false)) { if (!ContentReference.IsNullOrEmpty(link.OwnerID)) { contentRefs.Add(link.OwnerID); } } var siteIds = new HashSet<string>(); foreach (var contentRef in contentRefs) { var site = siteDefinitionResolver.GetByContent(contentRef, false); if (site != null) { siteIds.Add(site.Id.ToString()); } } objectCache.Insert(cacheKey, siteIds, new CacheEvictionPolicy( TimeSpan.FromMinutes(120), CacheTimeoutType.Sliding, [contentCacheKeyCreator.VersionKey])); return siteIds; } } return [content.SiteId()]; } public static Dictionary<string, LanguagePublicationStatus> PublishedInLanguage(this IContentMedia content, bool foobar) { content.ValidateNotNullArgument(nameof(content)); if (ContentReference.IsNullOrEmpty(content?.ContentLink)) { return null; } var contentLoader = _contentLoader.Value; var contentRepository = _contentRepository.Value; var versionRepository = _versionContentRepository.Value; var objectCache = _objectCache.Value; var contentCacheKeyCreator = _contentCacheKeyCreator.Value; if (contentLoader.GetAncestors(content.ContentLink) .Any(x => x.ContentLink == ContentReference.GlobalBlockFolder)) { // Should we need to check whether entire ancestor chain are resolvable? var cacheKey = $"Languages:{content.ContentLink.ID}"; var cachedLanguages = objectCache.Get(cacheKey) as Dictionary<string, LanguagePublicationStatus>; if (cachedLanguages != null) { return cachedLanguages; } var contentRefs = new HashSet<ContentReference>(); foreach (var link in contentRepository.GetReferencesToContent(content.ContentLink, false)) { if (!ContentReference.IsNullOrEmpty(link.OwnerID)) { contentRefs.Add(link.OwnerID); } } var languages = new Dictionary<string, LanguagePublicationStatus>(StringComparer.OrdinalIgnoreCase); foreach (var contentRef in contentRefs) { var publishedLanguages = versionRepository .ListPublished(contentRef) .Select(x => x.LanguageBranch); foreach (var lang in publishedLanguages) { if (contentLoader.TryGet<IContent>(contentRef, new LanguageSelector(lang), out var contentInLang)) { var langStatus = contentInLang.PublishedInLanguage(); if (langStatus != null) { foreach (var kvp in langStatus) { languages.TryAdd(kvp.Key, kvp.Value); } } } } } objectCache.Insert(cacheKey, languages, new CacheEvictionPolicy( TimeSpan.FromMinutes(120), CacheTimeoutType.Sliding, [contentCacheKeyCreator.VersionKey])); return languages; } return content.PublishedInLanguage(); } } </code></pre> <h2>What It Looks Like in the Index</h2> After reindexing a global asset referenced across different sites and languages, it will now include enriched metadata, like this <pre class="language-javascript"><code>"PublishedInLanguage": { "sv": { "StartPublish$$date": "2017-02-22T11:24:00Z" }, "fi": { "StartPublish$$date": "2025-06-18T11:03:00Z" }, "en": { "StartPublish$$date": "2012-10-04T11:53:00Z" }, "en-GB": { "StartPublish$$date": "2025-05-21T06:24:00Z" } }, "SiteId": [ "site-a-guid", "site-b-guid" ]</code></pre>2025-06-26T16:11:48.0000000Z

Blog post

Create a multi-site aware custom search provider using Search & NavigationIn a multisite setup using Optimizely CMS, searching for pages can be confusing. The default CMS search regardless of search provider does not clearly indicate which site a given result belongs to—especially when you have identical page names across multiple sites. This post shows how you can create a custom search provider, using Search & Navigation, to make your search results site-aware. <h2>Solution</h2> By creating a custom search provider that appends site context (like the start page or site name) to each result, you can make the search output clearer and easier to work with. In the example below, we add the start page name as a suffix to the page title in the results. This makes it obvious which site a page belongs to. Pages that are not under any site start page appear without a suffix and show up at the top of the results, since they are not associated with any specific site.  <blockquote> You can easily adapt this to use the site name instead of the start page name if you prefer. </blockquote> This code is provided as-is, without guarantees or support. However, I’d be happy to hear your feedback or thoughts in the comments. <h2>Implement it</h2> <ol> <li> Add new class MultiSitePageSearchProvider.cs to your solution. Attached further down. </li> <li> In Admin mode > Settings -> Search Configuration, enable the new Find pages (Multisite) provider and disable the default Find pages provider. </li> <li> Try a few searches in edit mode and confirm that results now show which site they belong to. </li> </ol> <h2>Example results before</h2> <img src="/link/ca9ad5c76b334506ba3cf5c898defcd3.aspx" alt="" width="359" height="346" /> <h2>... and after</h2> <img src="/link/d10534120a684ba8b3fbe10102758411.aspx" alt="" width="375" height="367" />   MultiSitePageSearchProvider.cs <pre class="language-csharp"><code>using EPiServer.Find; using EPiServer.Find.Framework; using EPiServer.Find.UI.Models; using EPiServer.Find.UnifiedSearch; using EPiServer.Framework; using EPiServer.Framework.Localization; using EPiServer.Globalization; using EPiServer.ServiceLocation; using EPiServer.Shell; using EPiServer.Shell.Search; using EPiServer.Web; using EPiServer.Web.Routing; using Newtonsoft.Json.Linq; namespace EPiServer.Find.Cms.SearchProviders { [SearchProvider] public class MultiSitePageSearchProvider : EnterprisePageSearchProvider { private readonly UIDescriptorRegistry _uiDescriptorRegistry; private readonly ISiteDefinitionRepository _siteDefinitionRepository; private readonly IContentLoader _contentLoader; private readonly IClient _searchClient; private readonly ILogger<MultiSitePageSearchProvider> _logger; private const string AllowedTypes = "allowedTypes"; private const string RestrictedTypes = "restrictedTypes"; public override string Area => FindContentSearchProviderConstants.PageArea; public override string Category => "Find pages (Multisite)"; public MultiSitePageSearchProvider( LocalizationService localizationService, ISiteDefinitionResolver siteDefinitionResolver, IContentTypeRepository<PageType> contentTypeRepository, UIDescriptorRegistry uiDescriptorRegistry, EditUrlResolver editUrlResolver, ServiceAccessor<SiteDefinition> siteDefinitionAccessor, IContentLanguageAccessor contentLanguageAccessor, IUrlResolver urlResolver, ITemplateResolver templateResolver, IContentRepository contentRepository, ISiteDefinitionRepository siteDefinitionRepository, IContentLoader contentLoader, IClient searchClient, ILogger<MultiSitePageSearchProvider> logger) : base(localizationService, siteDefinitionResolver, contentTypeRepository, uiDescriptorRegistry, editUrlResolver, siteDefinitionAccessor, contentLanguageAccessor, urlResolver, templateResolver, contentRepository) { _uiDescriptorRegistry = uiDescriptorRegistry; _siteDefinitionRepository = siteDefinitionRepository; _contentLoader = contentLoader; _searchClient = searchClient; _logger = logger; } public override IEnumerable<SearchResult> Search(Query query) { Validator.ThrowIfNull("SearchProviderFactory.Instance.AccessFilter", FilterFactory.Instance.ContentAccessFilter); Validator.ThrowIfNull("SearchProviderFactory.Instance.CultureFilter", FilterFactory.Instance.CultureFilter); Validator.ThrowIfNull("SearchProviderFactory.Instance.RootsFilter", FilterFactory.Instance.RootsFilter); query.MaxResults = 20; ITypeSearch<IContentData> searchQuery = GetFieldQuery(query.SearchQuery, query.MaxResults) .Filter(x => x.MatchTypeHierarchy(typeof(IContentData))); var allowedTypes = GetContentTypesFromQuery(AllowedTypes, query); var restrictedTypes = GetContentTypesFromQuery(RestrictedTypes, query); FilterContext filterContext = FilterContext.Create<IContentData, ContentType>(query); searchQuery = FilterFactory.Instance.AllowedTypesFilter(searchQuery, filterContext, allowedTypes); searchQuery = FilterFactory.Instance.RestrictedTypesFilter(searchQuery, filterContext, restrictedTypes); searchQuery = FilterFactory.Instance.ContentAccessFilter(searchQuery, filterContext); searchQuery = FilterFactory.Instance.CultureFilter(searchQuery, filterContext); searchQuery = FilterFactory.Instance.RootsFilter(searchQuery, filterContext); var contentLinksWithLanguage = Enumerable.Empty<ContentInLanguageReference>(); try { contentLinksWithLanguage = searchQuery .Select(x => new ContentInLanguageReference( new ContentReference(((IContent)x).ContentLink.ID, ((IContent)x).ContentLink.ProviderName), ((ILocalizable)x).Language.Name)) .StaticallyCacheFor(TimeSpan.FromMinutes(1), UnifiedWeightsCache.ChangeToken) .GetResultAsync() .GetAwaiter() .GetResult(); } catch (Exception ex) { _logger.LogError(ex, "Error during CMS page search query execution: {Message}", ex.Message); return Enumerable.Empty<SearchResult>(); } PageData content = null; // Check if there are multiple sites with actual start pages var hasMultipleResolvableSites = _siteDefinitionRepository.List() .Where(site => !ContentReference.IsNullOrEmpty(site.StartPage) && _contentLoader.TryGet<IContent>(site.StartPage, out _)) .Skip(1) .Any(); return contentLinksWithLanguage .Where( searchResult => _contentLoader.TryGet<PageData>(searchResult.ContentLink, !String.IsNullOrEmpty(searchResult.Language) ? new LanguageSelector(searchResult.Language) : LanguageSelector.AutoDetect(true), out content)) .Select(item => { var result = CreateSearchResult(content); if (hasMultipleResolvableSites && Guid.TryParse(content.SiteId(), out var siteId)) { var site = _siteDefinitionRepository.List().FirstOrDefault(s => s.Id == siteId); if (site != null) { var startPageName = _contentLoader.Get<IContent>(site.StartPage)?.Name; if (!string.IsNullOrEmpty(startPageName)) { result.Metadata.Add("SortKey", startPageName); result.Title = $"{startPageName} \\ {result.Title}"; // Suffix the page title with the startPage name } } } return result; }) .OrderBy(x => x.Metadata.TryGetValue("SortKey", out var sortKey) ? sortKey : string.Empty); } private new ITypeSearch<IContentData> GetFieldQuery(string SearchQuery, int maxResults) { var language = ResolveSupportedLanguageBasedOnPreferredCulture(); if (String.IsNullOrEmpty(SearchQuery)) { SearchQuery = "*"; } var query = _searchClient.Search<IContentData>(language) .For(SearchQuery); if (StringExtensions.IsAbsoluteUrl(SearchQuery)) { query = query.InField(x => ((ISearchContent)x).SearchHitUrl); return query .Take(maxResults); } query = query.InField(x => ((IContent)x).Name, 10) .InField(x => ((IContent)x).ContentTypeName(), 0.5) .InField(x => x.SearchText()); int parsedQuery; if (int.TryParse(SearchQuery, out parsedQuery)) { query = query.InField(x => ((IContent)x).ContentLink.ID, 10); } DateTime parsedDate; if (DateTime.TryParse(SearchQuery, out parsedDate)) { query = query.InField(x => ((ISearchContent)x).SearchPublishDate.ToString()); } return query .Take(maxResults).SetTimeout(10000); } private IEnumerable<Type> GetContentTypesFromQuery(string parameter, Query query) { if (query.Parameters.ContainsKey(parameter)) { var array = query.Parameters[parameter] as JArray; if (array != null) { return array.Values<string>().SelectMany(GetContentTypes); } } return Enumerable.Empty<Type>(); } private new IEnumerable<Type> GetContentTypes(string allowedType) { var uiDescriptor = _uiDescriptorRegistry.UIDescriptors.FirstOrDefault(d => d.TypeIdentifier.Equals(allowedType, StringComparison.OrdinalIgnoreCase)); if (uiDescriptor == null) return Enumerable.Empty<Type>(); return _contentTypeRepository .List() .Where(c => uiDescriptor.ForType.IsAssignableFrom(c.ModelType)) .Select(c => c.ModelType); } private Language ResolveSupportedLanguageBasedOnPreferredCulture() { Language language = null; var preferredCulture = ContentLanguage.PreferredCulture; if (preferredCulture != null) { language = _searchClient.Settings.Languages.GetSupportedLanguage(preferredCulture); } language = language ?? Language.None; return language; } } } </code></pre>  2025-06-12T11:45:01.0000000Z

Blog post

Avoid Field Type Conflicts in Search & NavigationWhen using Optimizely Search & Navigation, reusing the same property name across different content types is fine — as long as the type is consistent. If one type uses int and another uses string, you'll run into indexing and query issues. <h2>💥 The Issue</h2> Optimizely Search & Navigation stores data in Elasticsearch, which assigns a data type to each field the first time it sees it. That type is then fixed. If CategoryId is first indexed as an int, any later document sending "12" (as a string) under the same field name causes a conflict. This can lead to: <ul> <li> Missing / fluctuating search results </li> <li> Filters not working </li> <li> Incorrect aggregations </li> <li> Indexing errors </li> </ul> <h2>🧪 Example</h2> <pre><code class="language-csharp">public virtual List<int> CategoryId { get; set; } // Used in one type public virtual List<string> CategoryId { get; set; } // Used in another </code></pre> Query: <pre><code class="language-json">"term": { "CategoryId": 12 } </code></pre> Only matches documents where CategoryId is an integer.  <h2>✅ How to Prevent It</h2> <ul> <li> Keep the same type for shared field names across all content types - at least for those content types you will be indexing. It can be good to know that this is not always an issue because we do suffix many types (string gets the suffix $$string) meaning a plain string property and an integer propery will be keyed differently in the mappings.  </li> </ul> <h2>🧱 Root Cause</h2> This is a limitation in Elasticsearch, not a bug in Optimizely Search & Navigation. Once a field is mapped with one type, it can’t accept another. <h2>✅ Summary</h2> <ul> <li> Same name + different type = broken queries </li> <li> Align types for all shared property names </li> <li> Use consistent modeling to avoid mapping conflicts </li> </ul>2025-06-05T09:21:59.0000000Z

Blog post

Avoid Deep Indexing of ContentAreas Unless NecessaryIn a typical Episerver CMS implementation, it’s common to encounter deeply nested structures — ContentAreas containing Blocks, which themselves contain more ContentAreas and Blocks, potentially going multiple levels deep. <h2>The Problem with Deep Nesting in Indexing</h2> By default, <a href="/link/9fa95469dbdd44cea3ed19aaf7e2a1cf.aspx">when indexing ContentAreas</a>, there’s no sensible maximum nesting depth enforced. Only the default JSON serialization max depth at 25.This can lead to: <ul> <li> Increased strain on the search service </li> <li> Longer indexing times </li> <li> Larger mapping sizes </li> <li> Degraded query performance </li> </ul> If you don’t specifically need to filter or retrieve deeply nested content, it’s a good idea to limit how deep the indexing goes. <h2>How to Limit ContentArea Depth</h2> This can be controlled using the MaxDepthContentAreaConverter. You can configure the maximum depth by adding the following code to your initialization module: <div class="contain-inline-size rounded-md border-[0.5px] border-token-border-medium relative bg-token-sidebar-surface-primary"> <div class="overflow-y-auto p-4"><code class="whitespace-pre! language-csharp">SearchClient.Instance.Conventions.ForInstancesOf<ContentArea>().ModifyContract(x => x.Converter = new MaxDepthContentAreaConverter(1)); </code></div> </div> This example limits the indexing depth to 1 level, but you can adjust the value based on your needs. This information is also available in our documentation: https://world.optimizely.com/documentation/Items/Developers-Guide/EPiServer-Find/11/Integration/episerver-77-5-cms/Indexing-content-in-a-content-area/ <h2>Important Note on SearchText</h2> Keep in mind, this setting only affects the serialization depth of ContentAreas for indexing purposes. It does not impact the maximum depth used by SearchText, which is responsible for collecting, concatenating, and indexing textual content within ContentAreas and their nested items. Meaning the content in your ContentArea will still be searchable.  2025-06-04T11:23:02.0000000Z

Blog post

Optimize your queries for performance and search relevanceWhen working with Search & Navigation, query optimization can have a massive impact on both performance and search quality. Here are some practical tips to help you tune your queries for better speed, lower resource usage, and more relevant search results. <h2>Use single terms query instead of multiple term OR queries</h2> If you're filtering on the same field with multiple term OR conditions, switch to using a terms filter. It’s more efficient and easier to maintain. In this code this translates to the following: ❌ Bad: <pre><code class="language-csharp">.Filter(x => x.ModelSize.Match("S") | x.ModelSize.Match("M") | x.ModelSize.Match("L")) </code></pre> ✅ Good: <pre><code class="language-csharp">.Filter(x => x.ModelSize.In(new[] { "S", "M", "L" })) </code></pre> The terms filter is cached in Elasticsearch. This significantly reduces CPU and memory load, speeds up queries, and minimizes shard access.   <h2>Improve Relevance by Boosting Exact Matches</h2> By default, queries may return results based on stemmed words, synonyms, or even compound terms. To improve relevance, you can explicitly boost exact matches using a custom extension method like InStandardField() below. <pre><code class="language-csharp">public static class QueryStringSearchExtensions { public static IQueriedSearch<TSource, QueryStringQuery> InStandardField<TSource, TExistingQuery>( this IQueriedSearch<TSource, TExistingQuery> search, Expression<Func<TSource, string>> fieldSelector, double? relativeImportance = null) where TExistingQuery : QueryStringQuery { fieldSelector.ValidateNotNullArgument("fieldSelector"); return search.InField( search.Client.Conventions.FieldNameConvention.GetFieldName((Expression)fieldSelector), relativeImportance); } } </code></pre> <h3>Usage</h3> <pre><code class="language-csharp"> .InStandardField(x => x.Name, 5) // Boost exact match by factor of 5 .InStandardField(x => x.SearchText, 5) // Boost exact match by factor of 5 .InField(x => x.Name) // Standard search .InField(x => x.SearchText); // Standard search </code></pre> <hr /> <h2>Example: Searching for "vei"</h2> Before Workaround (No boosting): Many of the matches are compound words or unrelated stems. <pre><code>"Karriereveiledningskonferansen" "Vegstrategi" "Vegforvaltning" "Fylkesveg" "Elektrisk vei" "Vegstrategi" "Delstrategi veg" "Nyheter fylkesveg" "Vegamot AS" "Stillinger veg" </code></pre> After Workaround (Boosted relevance): Results now prioritize exact matches: <pre><code>"Elektrisk vei" "Delstrategi veg" "Stillinger veg" "Kontaktinformasjon veg" "Veg-prosjekter" "Høringssvar delstrategi veg" "Søknad om reklame langs veg" "Fravik fra krav i vegnormal" "Trøndelagsmodellen - skreddersydd veg til sikker jobb" "Stenger veg i Overhalla" </code></pre> As you can see, the relevance of results is dramatically improved. Exact matches like "veg" are ranked higher, and compound or less-relevant terms are deprioritized. <h2>Summary</h2> <ul> <li>Replace term OR logic on the same field with terms filters to improve query performance.</li> <li>Use field boosting via extensions like InStandardField() to elevate exact matches over stemmed, synonyms or compound terms.</li> </ul> By following these patterns, you'll get faster queries and better results — a win-win for both backend performance and user satisfaction.2025-06-04T08:52:42.0000000Z

Blog post

Searching Breadcrumbs and Content and their AssetsRecently, I handled a couple of support cases that revolved around two challenges in a Search & Navigation. <ol> <li> Rendering breadcrumbs for search results, and </li> <li> Searching below a specific node and including content and content assets. </li> </ol> Neither problem was rocket science, but after digging in, testing, and writing some code, we ended up with ideas worth sharing. Hopefully, they’ll save you some time if you’re tackling something similar. <h2>Case #1: Searching Below a Specific Node (And Including Assets)</h2> Let’s say you're searching under a specific node (e.g. a section or page on your site). You want to include both pages and content assets (like PDFs, images, etc.) stored below this node. You might start with something like: <pre><code class="language-csharp">var result = SearchClient.Instance.UnifiedSearch() .For(q) .Filter(x => ((IContent)x).Ancestors().Match(node_to_search_below)) .GetResult(); </code></pre> This works perfectly for content pages, but not for content assets. Why? <h3>🧠 Why Assets Are Missing</h3> Assets are stored in a different structure than pages. Their Ancestors() path does not include the node you're filtering on. This is because assets like documents are typically stored in Asset Folders, which are often detached from your actual content hierarchy. <hr /> <h3>✅ Solution: Index Owner Ancestors for Assets</h3> We can solve this by populating a virtual field with the ancestors of the owning content for each asset. That way, assets "inherit" the path of their parent content at index time. <h4>Step 1: Extend MediaData With Owner Ancestors</h4> In your Find initialization module: <pre><code class="language-csharp">SearchClient.Instance.Conventions.ForInstancesOf<MediaData>() .IncludeField(x => x.ContentAncestors()); </code></pre> Then, add this helper extension method: <pre><code class="language-csharp">public static IEnumerable<string> ContentAncestors(this MediaData content) { var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>(); var contentAssetHelper = ServiceLocator.Current.GetInstance<ContentAssetHelper>(); var assetOwner = contentAssetHelper.GetAssetOwner(content.ContentLink); if (assetOwner != null) { var assetContent = contentRepository.Get<IContent>(assetOwner.ContentLink) as PageData; return assetContent?.Ancestors(); } return null; } </code></pre> This code retrieves the owning page of the asset and gets its Ancestors() so we can treat the asset as if it were part of the same structure. <hr /> <h4>Step 2: Update Your Search Query</h4> Now, combine the original ancestor filter with your new one: <pre><code class="language-csharp">var result = SearchClient.Instance.UnifiedSearch() .For(q) .Filter(x => ((IContent)x).Ancestors().Match(node_to_search_below) || ((MediaData)x).ContentAncestors().Match(node_to_search_below)) .GetResult(); </code></pre> Voilà — you now get results for both pages and their related assets. <hr /> <h2>Case #2: Generating Breadcrumbs from Search Results</h2> Breadcrumbs are often generated based on Ancestors(). While it’s possible to resolve these at render time, a more efficient approach is to index ancestor names so they’re available immediately from the search index. <h3>✅ Solution: Index Ancestor Names</h3> In your Find initialization code: <pre><code class="language-csharp">SearchClient.Instance.Conventions.ForInstancesOf<IContent>() .IncludeField(x => x.AncestorNames()); </code></pre> Then define the extension like this: <pre><code class="language-csharp">public static IEnumerable<string> AncestorNames(this IContent content) { var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>(); var ancestorNames = new List<string>(); foreach (var ancestorContentRef in content.Ancestors()) { var ancestorPage = contentRepository.Get<IContent>(new ContentReference(ancestorContentRef)) as PageData; if (ancestorPage != null) { ancestorNames.Add(ancestorPage.Name); } } return ancestorNames; } </code></pre> This way, your search results come with a breadcrumb trail like: <pre><code class="language-json">"AncestorNames": ["Start", "About Us", "Team"] </code></pre> You can use this directly to render navigation or path-based UX without additional lookups.    2025-06-04T08:50:28.0000000Z

Blog post

Improve performance by enabling language routing on search requestsIn Find 13, we <a href="/link/a60589764eca488ab205842da0714609.aspx">introduced language routing on indexing</a> to improve indexing performance for indexes setup with multiple languages. With the release of Find 13.4.9, we further introduced language routing on query time. We recommend moving up to 13.5.7 due to other bug fixes. This feature is also available in .NET flavours: 14.2.4 and 15.0.3 This feature enables passing the query only to the specific language index, rather than having all language indexes process the query even though most of them would only respond with 0 hits as we're usually filtering on language properties in the index. Since 13.5.1 this feature is disabled by default. To enable this feature, there are a few steps to follow: <ol> <li>Ensure that you explicitly or implicitly set the language for your query. You typically achieve this by using one of the following approaches: <pre class="language-csharp"><code>.Search<type>(language) or .UnifiedSearch(language)</code></pre> Alternatively, you can rely on the extensions provided by Episerver.Find.CMS and use <pre class="language-csharp"><code>.UnifiedSearch() or .UnifiedSearchFor()</code></pre> which will automatically set the preferred culture if you don't specify one. Be careful not to use the Episerver.Find extensions, as they do not resolve language. </li> <li>You can verify that everything is working correctly by checking the analyzer set in the JSON for the request against the _search.  It should say analyzer:[language]. If you are using .UsingSynonyms() it should say analyzer: synonym_[language_code]. </li> <li>If you are using CMS 11, you can do this in the web.config file by adding the following: <pre class="language-markup"><code><appSettings> <add key="episerver:EnableLanguageRoutingInSearchRequest" value="true"/></code></pre> If you are using CMS 12, you can do this in the appsettings.json file by adding the following: <pre class="language-markup"><code>"EPiServer": { "Find": { "EnableLanguageRoutingInSearchRequest":true } }</code></pre> </li> </ol> Note that if you have custom InField extension that makes it possible to query fields for multiple language fields, language routing query time cannot be used. Our tests have shown a decrease in response times of around 25% for queries with language routing enabled.  However, this improvement may vary depending on your implementation, the number of languages enabled on the index, and the data indexed. Find versions that support language routing on search requests <a href="https://nuget.optimizely.com/package/?id=EPiServer.Find&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;v=15.0.3">https://nuget.optimizely.com/package/?id=EPiServer.Find&v=15.0.3</a> <a href="https://nuget.optimizely.com/package/?id=EPiServer.Find&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;v=14.2.4">https://nuget.optimizely.com/package/?id=EPiServer.Find&v=14.2.4</a> <a href="https://nuget.optimizely.com/package/?id=EPiServer.Find&amp;amp;amp;v=13.5.7">https://nuget.optimizely.com/package/?id=EPiServer.Find&v=13.5.7</a>2023-04-03T15:16:32.0000000Z

Blog post

Unlisting Episerver.Find packages 13.4.9-13.5.1 and 14.1.0-14.2.2Dear partners and developers, Due to issues introduced with this change/release <a href="/link/76974ad8d2a84c1b989ad0ac453ab663.aspx?releaseNoteId=FIND-5191&epsremainingpath=ReleaseNote/">https://world.optimizely.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=FIND-5191</a> which impacts both clients and the Find service we are delisting the following Episerver.Find.* package from our NuGet feed with immidate effect with the exception of Episerver.Find.Commerce. <ul> <li>13.4.9, 13.5.1, 14.1.0, 14.2.1, 14.2.2 If you're on any of these versions mentioned above make you sure you upgrade. Note that unlisting packages will still let you install them if you're already referencing them. </li> </ul> These issues caused the following symptoms: <ul> <li>Updating content with child content often incorrectly causes child content to get reindexed which consumes unneccessary resources from both web app and Find cluster.</li> <li>Delays in updates i.e. delete, save and publishing, to reflect in the Find index due to indexing queue growing large.</li> <li>Performance issues in the CMS UI.</li> </ul> These issues were fixed with releases 13.5.2 and 14.2.4. More information available here <a href="/link/76974ad8d2a84c1b989ad0ac453ab663.aspx?releaseNoteId=FIND-10852&epsremainingpath=ReleaseNote/">https://world.optimizely.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=FIND-10852</a> 2023-01-17T13:29:21.0000000Z

Blog post

Configure your own Search & Navigation timeoutsChanging the timeout for Search & Navigation requests is something that has been requested over and over in forums and support cases for quite some time. The default request timeout is set to 100 seconds (HttpWebRequest.Timeout default) which could be problematic when requests takes longer than expected. <h3>You might know that you can set the request timeout in configuration</h3> This will be used for all types of Find requests and could pose a problem if you want to lower it to 10 secs but at the same time not affect requests that should be allowed to run longer e.g bulk requests. Timeout is set in milliseconds. CMS 11 and lower <pre class="language-javascript"><code><appSettings><add key="episerver:FindDefaultRequestTimeout" value="30000" /></code></pre> CMS 12 <pre class="language-javascript"><code> "AppSettings": { "episerver:FindDefaultRequestTimeout": 30000 }</code></pre> More on configuration here <a href="/link/20894744d88447cf8986cd46db0b543b.aspx">https://world.optimizely.com/documentation/developer-guides/CMS/configuration/</a> <h3>But it's also possible with some code to set the timeout for a specific request</h3> Add the following extension methods <pre class="language-csharp"><code>public static ITypeSearch<TResult> SetTimeout<TResult>(this ITypeSearch<TResult> search, int timeout) { return new Search<TResult, IQuery>(search, context => { var existingAction = context.CommandAction; context.CommandAction = command => { if (existingAction.IsNotNull()) { existingAction(command); } command.ExplicitRequestTimeout = timeout; }; }); } public static ISearch<TResult> SetTimeout<TResult>(this ISearch<TResult> search, int timeout) { return new Search<TResult, IQuery>(search, context => { var existingAction = context.CommandAction; context.CommandAction = command => { if (existingAction.IsNotNull()) { existingAction(command); } command.ExplicitRequestTimeout = timeout; }; }); } public static IMultiSearch<TResult> SetTimeout<TResult>(this IMultiSearch<TResult> multiSearch, int timeout) { var searches = new List<ISearch<TResult>>(multiSearch.Searches); multiSearch.Searches.Clear(); foreach (var search in searches) { multiSearch.Searches.Add(SetTimeout(search, timeout)); } return multiSearch; }</code></pre> And use it like this <pre class="language-csharp"><code>var results = SearchClient.Instance .UnifiedSearch .For("random fruit") .SetTimeout(10000) .GetResult(); var results = searchClient.Search<Fruits> .For("banana") .SetTimeout(1000) .GetResult(); var results = searchClient.MultiSearch<Fruits>() .Search<Exotic>(x => x.For("Kiwi").InField(y => y.SearchTitle())) .Search<Ordinary>(x => x.For("Apple").InField(y => y.SearchTitle())) .SetTimeout(1000) .GetResult();</code></pre> Make sure you catch your timeouts. They will throw a ServiceException. More on Find exceptions you should consider catching is available in Jonas Bergqvist's blog post <a href="/link/3a36ccb7fc0e485194070a4b38adfb44.aspx">Exceptions in find </a>2022-01-28T14:44:10.0000000Z

Blog post

How to make Find 13.x play nice with Find on-premiseIf you are using Find (Search & Navigation) 13.x or later with an index located on a Find on-premise instance you need to do the following to achieve full compatibility.  This is not applicable to any solution where you're using an index hosted by EPiServer. 1. If you are on 13.0.5 or later you need to make sure you upgrade to at least 13.2.4 and add useLegacySorting=true to your episerver.find config element to be     able to use the Elastic Search sorting functionality to it's full extent. <pre class="language-csharp"><code><episerver.find serviceurl="..." useLegacySorting="true" ... ></code></pre> <code></code>2. With Find 13 language routing was introduced. This is not available on Find on-premise therefor you should disable it.     Disable Language Routing support via LanguageRoutingFactory.  <code></code> <pre class="language-csharp"><code> [InitializableModule] [ModuleDependency(typeof(IndexingModule))] public class MyFindInitializationModule : IConfigurableModule { public void Initialize(InitializationEngine context) { } public void Uninitialize(InitializationEngine context) { } public void ConfigureContainer(ServiceConfigurationContext context) { context.Services.AddSingleton<LanguageRoutingFactory, MyLanguageRoutingFactory>(); } } public class MyLanguageRoutingFactory : LanguageRoutingFactory { public override LanguageRouting CreateLanguageRouting(ILocale locale) { return null; } } }</code></pre> <code></code><code></code>2020-10-13T10:12:29.0000000Z

Blog post

Improving synonyms and overall search experienceIs your Search & Navigation (Find) implementation affected by the limitations of the current synonym functionality and/or would you like to improve upon the overall search experience?  Check out <a href="https://github.com/episerver/EPiServer.Labs.Find.Toolbox">https://github.com/episerver/EPiServer.Labs.Find.Toolbox</a> Setup and configuration is simple. Install NuGet Package and then there are a couple of lines of code to get it working. What you get <ul> <li>An improved synonym implementation (No more issues with synonyms in conjuction with .WithAndAsDefaultOperator)</li> <li>An overall relevance improvement by utilising MatchPhrase, MatchPhrasePrefix and MatchPrefix</li> <li>Support for MinimumShouldMatch which improves search experience further</li> <li>FuzzyMatch and WildcardMatch improving searches with typos and partial words</li> </ul> All can be used together or independently and depends on the .For() call for the original query Full details available in README  https://github.com/episerver/EPiServer.Labs.Find.Toolbox/blob/master/README.md Feedback and input are welcome and don't hesitate to contribute if you'd like. Please note that this project is not officially supported by Episerver just like most EPiServer.Labs projects. Should be considered stable and is currently used in production environments. UPDATE 2021-01-09 New version 1.1.1. Bugfix for bidrectional multi term synonyms Boost adjustment for PrefixQueries UPDATE 2020-10-14 New version 1.1.0. Further improvements to relevance with the addition of .UsingRelevanceImprove() which combines the powers of Elastic Search's MatchPhrase, MatchPhrasePrefix and MatchPrefix. UPDATE 2020-09-08 Bugfixes and improvements and new version 1.0.9. UPDATE 2020-09-03 Project renamed to Find Toolbox @ <a href="https://github.com/episerver/EPiServer.Labs.Find.Toolbox">https://github.com/episerver/EPiServer.Labs.Find.Toolbox</a> Now with new features to improve search relevance and overall search experience even further.  2020-06-24T19:14:45.0000000Z

Blog post

Why is my Find indexing job freezing and dying?I recently had a support case which I spent maybe a few hours too many on. The symptom was a find indexing job running for about 5 minutes, web app froze up and restarted causing the indexing job to fail prematurly. After looking into application logs, cpu and memory usage (which looked good overall) we could see the app were being restarted . We did profiling with some hints that the scheduled job thread was aborted. We then took a memory dump 4 minutes into the indexing job. In the memory dump we could see StackOverflowException, OutOfMemoryException and ThreadAbortException. After some more digging we found a call to a custom IsSearchable() for the same content over and over. This behaviour was due to self-referencing content and some custom logic that made it index the same content over and over. For future cases I'm gonna use something like below to more easily identify errors like this without profiling or memory dumps. Run the indexing job and check the logs for 'This content was recently indexed' and it might give you a hint on what it's getting stuck on.<code></code> <code></code> <pre class="language-csharp"><code>[InitializableModule] [ModuleDependency(typeof(EPiServer.Web.InitializationModule))] public class InitializationModule2 : IInitializableModule { protected static readonly ILog _logger = LogManager.GetLogger(typeof(ContentIndexer)); public void Initialize(InitializationEngine context) { var previouslyIndexedObjects = new Queue<int>(); int maxLookBack = 1000; ContentIndexer.Instance.Conventions.ForInstancesOf<IContent>().ShouldIndex(x => { _logger.Info(string.Format("Attempting to index content ID: {0 } Name: {1}", x.ContentLink.ID.ToString(), x.Name.ToString())); if (previouslyIndexedObjects.Contains(x.ContentLink.ID)) { _logger.Error(string.Format("WARNING! This content was recently indexed: {0 } Name: {1}", x.ContentLink.ID.ToString(), x.Name.ToString())); } if (previouslyIndexedObjects.Count() == maxLookBack) { previouslyIndexedObjects.Dequeue(); } previouslyIndexedObjects.Enqueue(x.ContentLink.ID); return true; });</code></pre> <code> </code>...2020-04-03T11:01:10.0000000Z

Blog post

Common Find caching pitfallsUnder certain conditions, the cache duration set with .StaticallyCacheFor(minutes) does not last as long as specified. There are three common reasons for this. More on .StatisticallyCacheFor can be found here <a href="/link/ad2f9694543c42c0a54a11bf2a76d2ec.aspx">https://world.episerver.com/documentation/developer-guides/find/NET-Client-API/searching/Caching/</a> <h3>.Filter() on a datetime property</h3> Any .Filter() on a datetime property with second (or finer) resolution should be rounded up to the nearest minutes matching the wanted cache duration. As the cache key is based on the query payload we don't want it to change more frequently than the cache duration otherwise we will rarely utilise the cache as a new cache is generated for every request and a new request sent to the Find service.  Here is an example of such a filter extracted from the JSON sent to the _search endpoint. You could inspect your requests with <a href="https://www.telerik.com/fiddler">Fiddler</a>. <pre>"range": { "EndDate$$date": { "from": "2019-01-24T20:59:59Z", "to": "9999-12-31T23:59:59.9999999Z", "include_lower": false, "include_upper": true } }</pre> <h3> .FilterForVisitor()</h3> .FilterForVisitor is a set of filters including .ExcludeDelete, .PublishedInCurrentLanguage, and .FilterOnReadAccess. .PublishedInCurrentLanguage contains a filter on a datetime and as such is affected by the same issue described in point #1. In a later version of Find (13.1) the datetime sent through to the .PublishedInCurrentLanguage() method uses a NOW() function instead of an actual value and is therefor not affected by this. If on an earlier version, replace .FilterForVisitor() with the individual filters and round up the datetime used with PublishedInCurrentLanguage() just as you would have if you've used a custom datetime filter as pointed out earlier. <h3>.GetContentResult()</h3> When using .GetContentResult() unlike .GetResult() there is a cache dependency on published content. If there are any updates cache will be evicted. For Commerce sites updates are typically frequent and could therefore have a negative impact on cache. Our recommendation is to use a custom .GetContentResult() where cache with this dependency is bypassed. This is commented out here. Don't forget to add your .StaticallyCacheFor() to control the cache duration. <pre> public static IContentResult<TContentData> GetContentResult<TContentData>(this ITypeSearch<TContentData> search, int cacheForSeconds = 60, bool cacheForEditorsAndAdmins = false) where TContentData : IContentData { if (typeof(IContent).IsAssignableFrom(typeof(IContent))) { search = search.Filter(x => ((IContentData)x).MatchTypeHierarchy(typeof(IContent))); } var projectedSearch = search .Select(x => new ContentInLanguageReference( new ContentReference(((IContent)x).ContentLink.ID, ((IContent)x).ContentLink.ProviderName), ((ILocalizable) x).Language.Name)); //Apply caching for non-editors //if (cacheForEditorsAndAdmins || !(PrincipalInfo.HasEditAccess || PrincipalInfo.HasAdminAccess)) //{ // var cacheSettings = ServiceLocator.Current.GetInstance<IContentCacheKeyCreator>(); // projectedSearch = projectedSearch.StaticallyCacheFor(TimeSpan.FromSeconds(cacheForSeconds), new CacheDependency(null, new string[] { cacheSettings.RootKeyName })); //} var searchResult = projectedSearch.GetResult(); var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>(); var fetchedContent = new Dictionary<ContentInLanguageReference, IContent>(); foreach (var language in searchResult.GroupBy(x => x.Language)) { foreach (var content in contentRepository.GetItems(language.Select(x => x.ContentLink).ToList(), new LanguageSelector(language.Key))) { fetchedContent[new ContentInLanguageReference(content)] = content; } } var sortedContent = new List<TContentData>(); foreach (var reference in searchResult) { IContent content; if (fetchedContent.TryGetValue(reference, out content) && content is TContentData) { sortedContent.Add((TContentData)content); } else { log.WarnFormat("Search results contain reference to a content with reference \"{0}\" in language \"{1}\" but no such content could been found.", reference.ContentLink, reference.Language); } } return new ContentResult<TContentData>(sortedContent, searchResult);</pre>2019-01-25T17:48:49.0000000Z

Blog post