November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
Hi, Matthew,
I see this is an old post, but have you come to resolution of it? I have exactly the same issue in 7.5.
Hi Marija
I worked through it with EPiServer support and ultimately was solved by using the orphaned page http://yoursite/EPiServer/CMS/Admin/IndexContent.aspx to force a full reindex. Once this had completed my queries were then correct.
Hopefully this solves it for you too :)
Matt
Hey Matthew, the problem for me was that indexing wasn't working from time to time. In the end, the following thing saved my day: instead of having a path using [appDataPath] variable
directoryPath="[appDataPath]\Index"
I've put an absolute path to Index:
directoryPath="\\serverpath\VPP\Index"
Then, I had no more errors logged when running the IndexContent.aspx.
In the end, this didn't help either (it did, but it go broken again) - I suppose it's related to multiple site bindings. In the end I upgraded to 7.7 and now it's stable.
I'm experiencing an issue where recycling bin content is being returned in search queries. The website is built on EPiServer v7 and is a fairly simple website with straight forward content using EPiServer FTS for search.
Further detail:
The lucene query sent to EPiServer FTS is the following:
I've bolded the key line of the query to focus. This defines the virtual path that FTS should filter the query of content to. The guid “43f936c9\-9b23\-4ea3\-97b2\-61c538ad07c9” represents the very root node of the site (id 1) and the next guid “5ef8dbb4\-92c0\-4ed2\-9235\-94de3f3a9aad” is the start page of the site – this path looks correct to me as it’s the full path to the start page and has the wildcard to allow all descendants to match. But strangely, though we get content we want, we also get items in the recycle bin.
As an example one of the offending results (in the recycle bin) has the virtual path “43f936c9-9b23-4ea3-97b2-61c538ad07c9|2f40ba47-f4fc-47ae-a244-0b909d4cf988|53ef3bd3-d9e7-4842-ad10-ee3edf7a5761|e4e4889f-ce2a-450b-acdf-bec22e45baa9” which to me shouldn’t be returned since the second item in its path doesn’t match the search filter.
I’m not sure if the index is out of sync or whether the querying has an issue. Any thoughts would be appreciated :)