Packages [expand] [collapse]

Release notes for Episerver updates

This overview lists changes included in Episerver updates delivered as NuGet packages and services. Use the information to decide which updates to apply to your project, see Installing Episerver updates. Select a product, package, or service in the left menu, and filter for dates, features, or bug fixes.

  • See only new features (all features) - filter on item type Feature.
  • See only end-user (user interface) features - filter on item type UI Feature.
  • See only critical bug fixes - filter on item type Critical Bug.

Note: New NuGet packages listed here may not be immediately available in the Episerver NuGet feed.

Changes in Find:

Item type
From date
To date
Area Id Type Description Released
  SiteDefinition.Current is not set in IndexingJobService

Error in EPiServer.Find.Cms.IndexingJobService.Start(Action<string> statusNotification).

SiteDefinition.Current was set to the site definition that was being indexed during Find indexing job in 13.0.5 and earlier versions. Setting SiteDefinition.Current is missing in 13.2.1, and should be added again.

Fix Version/s: EPiServer.Find 13.2.10;
Oct 23, 2020
  Additional dynamic proxy types as a result of CMS-15856 are impacting search

EPiServer.CMS.Core 11.18.0 creates additional DynamicProxy types which might increase the number of indexed items.

Fix Version/s: EPiServer.Find 13.2.9;
Sep 13, 2020
  Scheduled job: Remove old content should not execute in case of a 503 response during indexing

Scheduled job to remove old content must not execute in case of a 503 response during indexing.

Steps to reproduce:
1. Run indexing job, and check number in the index
2. Set an account to "read-only" mode by help from RE
3. Start indexing job
4. Change the account to normal mode by help from RE (to not be in read-only mode)
5. Wait until indexing job has finalized
6. Check number of items in the index

Expected: Same number of items after (1) as after (6)
Actual: Sometimes different, pending if (4) was done before the indexing job was completed.

Fix Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
  Media urls does not resolve when outside http context

Steps to reproduce

1. Set up multi site with Alloy and a Find index running the latest CMS and Find (2019-11-18)

2. I have three sites set up and use site specific assets; localhost (has a wildcard host), and

3. Media uploaded to localhost gets indexed in Find with an url that looks like this
http://[domain]/[lang]/SiteAssets/ (See SearchHitUrl$$string in Find index)

4. Media uploaded to, gets an url with http://[domain]/[lang]/SysSiteAssets/

5. If I remove wildcard host on localhost site media uploaded also get http://[domain]/[lang]/SysSiteAssets/

Is this correct behavior?
Client is expecting all to end up below http://[domain]/[lang]/SiteAssets/
I am not sure what is correct. I am not sure if this is really Find related either.

Fix Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
  Unnecessary allocations in ProjectionHelper.DeserializeObject

typeProperty.Parent is converted to string, then replace NewLine with empty, which creates 2 strings. That seems to be avoidable.

Fix Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
  Race conditions in indexing queue

It is not uncommon that clients complain about pages that are not updated through event indexing. We can often see that an indexing is performed but not with the latest version.

The App Support team has two possible theories on why this happens. One is described here: FIND-4176. The next is described below:

  1. Page A is saved which will add an item to the indexing queue.
  2. The queue is polled, the objects are retrieved from the db, serialized and pushed to Find. The thread is awaiting a response from Find...
  3. Meanwhile, page A is published and another item is added to the queue (it will have the same hash).
  4. A 200 OK is returned from Find, the indexing queue synchronize and purges the queue from all items with the same hash as A. The new published state will never be handled.

This typically happens when stuff is done in event handlers that slow up the process which creates a "perfect time gap".

Possible fixes

  1. Don't delete items from the queue that was added after the last LoadItems was performed.
  2. Only add content to the queue if either the content version that triggered the event has VersionStatus. Published or no version of the content is published.
Fix Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
  BestBetRepository does not utilize cache

BestBetRepository does not have cache so it will hit database almost everytime. Even worse, it uses DDS which has very bad performance.

Fix Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
  Adding bool to indexed content using projection cause exception

Adding a bool to an existing class that already have been indexed by content, and using the new property in projection will cause an exception

Steps to reproduce:
1. Index the Alloy site
2. Add the following search query in StartPageController:
.Select(x => new

{ x.MainBody }

3. Add a new property of typ bool in StartPage class
public class StandardPage : SitePageData
public virtual bool Testing

{ get; set; }

4. Add the new property to our projection in (2)
.Select(x => new

{ x.MainBody, x.Testing }

5. Start the site and go to the start page

Expected: No exception
Actually: Exception is thrown

Fix Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
  Register nested conventions once, not for each implementation

When applying nested convention for types having multiple implementations, the convention should only be registered once.

Fix Version/s: EPiServer.Find 13.2.7-pre-001130; EPiServer.Find 13.2.7;
May 06, 2020
  SearchText can return null reference exception

In edge cases, EPiServer.Find.Cms.ContentExtensions.SearchText(IContentData contentData) can return a null reference exception.

Fix Version/s: EPiServer.Find 13.2.7-pre-001130; EPiServer.Find 13.2.7;
May 06, 2020
1 2 3 4 5 6 Next