Products
Packages [expand] [collapse]
Services
Released in version
13.2.7-pre-001130
13.2.10
13.2.9
13.2.8
13.2.6
13.2.5
13.2.4
13.2.3
13.2.2
13.2.1
13.2.0
13.1.1
13.0.5
13.0.4
13.0.3
13.0.1
13.0.0
12.7.1
12.7.0
12.6.2
12.6.1
12.5.3
12.5.2
12.5.1
12.5.0
12.4.3
12.4.2
12.4.1
12.4.0
12.3.3
12.3.2
12.3.1
12.3.0
12.2.8
12.2.7
12.2.6
12.2.5
12.2.4
12.2.3
12.2.2
12.2.1
12.2.0
12.1.0
12.0.1
12.0.0
11.1.6.4396
11.1.5
11.1.4
11.1.3
11.1.2
11.1.1
11.1.0
11.0.0
10.1.4
10.1.0
10.0.0
9.2.3

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 or package, and filter for dates, features, or bug fixes.

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

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

Changes in EPiServer.Find

Item type
From date
To date
Items/Page
Id Type Title Released
FIND-6184
  SiteDefinition.Current is not set in IndexingJobService

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

Details
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.

Version/s: EPiServer.Find 13.2.10;
Oct 23, 2020
FIND-8423
  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.

Version/s: EPiServer.Find 13.2.9;
Sep 13, 2020
FIND-8047
  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.

Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
FIND-7998
  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), sitea.com and siteb.com

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 sitea.com, siteb.com 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.

Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
FIND-8165
  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.

Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
FIND-5970
  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.
Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
FIND-8039
  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:
SearchClient.Instance.Search<StandardPage>()
.Select(x => new

{ x.MainBody }

)
.GetResult();
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)
SearchClient.Instance.Search<StandardPage>()
.Select(x => new

{ x.MainBody, x.Testing }

)
.GetResult();
5. Start the site and go to the start page

Expected: No exception
Actually: Exception is thrown

Version/s: EPiServer.Find 13.2.8;
Jul 22, 2020
FIND-7560
  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.

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

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

Version/s: EPiServer.Find 13.2.7-pre-001130; EPiServer.Find 13.2.7;
May 06, 2020
FIND-7309
  Optimize event-driven indexing

When multiple content are changed, load multiple content per language to optimize performance when having multiple languages.

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