SaaS CMS has officially launched! Learn more now.

UnifiedSearch yields no results in WebApi

Vote:
 

Ok, this is pretty weird. When executing unified search in page controller context - it's working as expected (sample code):

 

public class SearchPageController : PageControllerBase<SearchPage>
{
    public ViewResult Index(SearchPage currentPage, string q)
    {
        var ctrl = new SearchController();
        var results = ctrl.Search(new SearchRequest { Query = q, PageSize = currentPage.ResultsCount });
        return View(new SearchPageViewModel(currentPage, q, results));
    }
}

    

WebApi controller:

public class SearchController : ApiController
{
    [HttpGet]
    public UnifiedSearchResults Search([FromUri] SearchRequest request)
    {
        var hitSpec = new HitSpecification
                      {
                          HighlightExcerpt = true,
                          ExcerptLength = 250,
                          PreTagForAllHighlights = "<strong><em>",
                          PostTagForAllHighlights = "</em></strong>"
                      };

        var results = SearchClient.Instance.UnifiedSearchFor(request.Query)
            .TermsFacetFor(p => p.SearchSection)
            .Skip(request.Page * request.PageSize)
            .Take(request.PageSize)
            .GetResult(hitSpec);

        return results;
    }
}

    

 

When accessing WebApi directly from client-side the same method it yields zero results (SearchRequest parameter in WebApi *is* binded correctly):

$.getJSON('/Api/Search/Search', { Query: q.val(), Page: 1, PageSize: 10 }, function (data) {
    alert(data);
});

    

#74013
Aug 17, 2013 9:38
Vote:
 

What is the value of results when using ajax to call it?

#74015
Aug 17, 2013 11:15
Vote:
 

Result is [].

Results are empty already on server side.

#74017
Aug 17, 2013 17:59
Vote:
 

Same behavior if you make the call using the HttpClient class instead of instansiating the SearchController in SearchPageController´s Index method?

#74020
Aug 18, 2013 13:55
Vote:
 

Hi Valdis,

I might guess that your problem is the skip/take. Your API call will set skip = 10 and Take = 10 meaning that you fetch page 11 to 20. If you set Page = 0 you will get the first 10 pages.

Regards,

Henrik

#74025
Aug 19, 2013 9:27
Vote:
 

I can confirm that there is more than 50 hits. It's the case even without any paging. I'll try to compare packages sent to Find..

#74027
Aug 19, 2013 10:01
Vote:
 

Did you find any solution to this. It seems that we have the same problem. GetFilesResult and GetResult for pages gives results, but when I use UnifiedSearchFor, no results gets returned. 

The code I use for UnifiedSearchFor looks like this (using a query that yields results in the two other cases as mentioned):

ITypeSearch<ISearchContent> search = SearchClient.Instance.UnifiedSearchFor(query, Language.Norwegian);
UnifiedSearchResults res = search.GetResult();

#74529
Aug 30, 2013 12:44
Vote:
 

Could you check the optional parameters for the GetResult method and try to set the one for filtering for public display (or something like that) to false? I find it hard to believe, but it may be related to the access rights filtering.

#74532
Aug 30, 2013 13:15
Vote:
 

That did the trick Joel.

i.e, the code now looks like this and gives results:

ITypeSearch<ISearchContent> search = SearchClient.Instance.UnifiedSearchFor(query, Language.Norwegian);
UnifiedSearchResults res = search.GetResult(new HitSpecification(), false);

#74533
Edited, Aug 30, 2013 13:33
Vote:
 

Cool, but now unpublished content or content that a public visitor doesn't have read access to may appear in the result. I'm not entirely sure how to fix that as it depends on how CurrentPrincipal works. 

#74534
Aug 30, 2013 13:35
Vote:
 

You know, my story is a bit different :) Without any changes either in code, index content or anything elsewhere - it started to give results back. I believe that this could be related with something happened on find service side.

#74550
Aug 31, 2013 13:15
Vote:
 

I suspect this to be a bug in EPiServer Find when specifying a language (which we are still experiencing...)

In our case we have an index for Norwegian and English. English works as expected, but when specifying Norwegian (either in UnifiedSearchFor-method, or FilterOnLanguages) we always get zero hits.

I've investigated this in Fiddler, and it seems like Language.Name$$string is always set to "en" no matter which language we specify.

The workaround suggested by Joel, works fine - but as stated, this also returns all hits even if the current user doesn't have access to them (by access control or publish status).

Has anyone found a good solution to this ?

#122347
May 31, 2015 23:58
Vote:
 

UnifiedSearch will by default filter on your current language branch. If you want to override this behaviour you have to use:

.OverrideCurrentLanguage("sv")


/Henrik

#122437
Jun 02, 2015 15:46
Vote:
 

I also came to this problem in my current Commerce project (all my products are visible to everyone) and Joel's suggestion worked like a charm. However, as he said it would cause unpublished contents showing in the search results. Is it still a bug in EPi find? 

 public UnifiedSearchResults SiteSearch(string keybowrd)
        {            
            return _client.UnifiedSearchFor(keybowrd)
                .UsingAutoBoost()   
                .Track()
                .Take(100)     
// *** GetResult() came back with empty results.   ****
                .GetResult(new HitSpecification(),false);
        }

Latest version Commerce + Find

#144651
Edited, Feb 17, 2016 2:53
Vote:
 

If you have any kind of OWin initialization in your project, e.g. the ServiceApi or LiveMonitor, CurrentPrincipal in a WebApi call will not be set unless this is specified somewhere. Try setting CurrentPrincipal like this in the Web Api: 

IPrincipal principal = new GenericPrincipal(
    new GenericIdentity("myuser"), new string[] { "myrole" });
Thread.CurrentPrincipal = principal;
HttpContext.Current.User = principal;

If that works, you can move forward with proper propagation of CurrentPrincipal based on client authentication.

#144658
Feb 17, 2016 7:55
Vote:
 

I used this method in the cms controller, it should not be the concern. Secondly, is the unifiedsearch designed for site wide search? If yes, then why do i need to pass the principle to the method? In addition, if i used search method, with filter access , the expected results came back. Confuse....

#144675
Feb 17, 2016 11:29
Vote:
 

UnifiedSearch will (when having filter for public search set to 'true') filter by published content visible to the user in the current language and by current site. As for user and language it will fallback on 'all' if not set but as for site it will only show content visible to all sites if not set (in a multisite setup content can be part of either one of the sites or all of them. Here 'all' isn't all sites but rater shared content between all sites). If your site only contains content from one site it will then be filtered out completly if 'SiteDefinition.Current.Id'SiteDefinition.Current.Id' is not set. However if you wan't it to always search cross all sites you can update your public search filter and only filter on language and user:

client.Conventions.UnifiedSearchRegistry
   .ForInstanceOf<PageData>()
   .PublicSearchFilter((c, ctx) => c.BuildFilter<IContentData>()
   .FilterForVisitor(ctx.Language == null || ctx.Language == Language.None
      ? Languages.AllLanguagesSuffix
      : ctx.Language.FieldSuffix)
   .ExcludeContainerPages()
   .ExcludeContentFolders());

 /Henrik

#144737
Feb 18, 2016 11:04
Vote:
 

Thanks everyone for your help. 

The issue has been fixed by removing the "EPiServer.Find.Cms" using statement, I have no idea why my brain triggered me doing this, though I am still not clear what happened. 

using System.Collections.Generic;
using System.Linq;
using System.Web.Mvc;
using EPiServer;
using EPiServer.Core;
using EPiServer.Framework.DataAnnotations;
using EPiServer.Web.Mvc;
using Website.Models.Pages;
using EPiServer.Find.Framework;
/*
using EPiServer.Find.Cms;

Without this using statement, unifiedsearch works as expected.
*/ 

using EPiServer.Find;
using System.Threading;
namespace Website.Controllers
{
    public class StartPageController : PageController<StartPage>
    {
        public ActionResult Index(StartPage currentPage)
        {
            /* Implementation of action. You can create your own view model class that you pass to the view or
             * you can pass the page type for simpler templates */

            var results = SearchClient.Instance.UnifiedSearchFor("a").GetResult();

            var principal = Thread.CurrentPrincipal;

            return View(currentPage);
        }
    }
}


Can someone help to explain what happened behind the sense? 

Regards,

Vincent

#144898
Feb 22, 2016 12:15
Vote:
 

Support team said it's likely a bug. The issue has been logged into the system. 

#145162
Feb 26, 2016 0:51
Vote:
 

Wow - thank god I found this.

The same thing worked for me - removing the using statement - crazy!

#145575
Mar 07, 2016 12:42
Vote:
 

Just hit this problem when updating a client site from 7.19 to 8.11 (to fix the Chrome 67 edit bug - alas, we don't have approval to take it all the way to EPi 11).

What I found:

  • UnifiedSearch worked fine IF no Filters were applied to the query. As soon as one filter was applied, even if it was .MatchTypeHierarchy(typeof(PageData)), I would get no results.
  • Removing the EPiServer.Find.CMS namespace didn't fix this for me (and we need it for some of our advanced filters)
  • Joel's suggestion of setting filterForPublicSearch = false when calling GetResults did work, but obviously this then shows content which should be restricted.

My solution was to shift the filterForPublicSearch behaviour into my query, then call GetResults with filterForPublicSearch set to false. Eventually worked out the easiest way to do this was to add a convention to my Find Initialization module:

SearchClient.Instance.Conventions.UnifiedSearchRegistry
	.Add<IContentSecurable>()
	.AlwaysApplyFilter(c => c.BuildFilter<IContentSecurable>()
		.And(content => content.RolesWithReadAccess().Match("Everyone")));

(adapted from http://world.episerver.com/Forum/Developer-forum/EPiServer-Search/Thread-Container/2013/6/Unified-Search---Excluding-pages-by-property/)

This seems to do the trick, and gets me the same results as I had in EPiServer 7.19.

Was the root cause of this ever discovered/fixed, and in which version? It would be useful to add a comment for future developers, but I can't find any bug tickets which refer to this. I appreciate UnifiedSearch seems to be a bit of a niche concern these days.

#195056
Edited, Jul 12, 2018 10:51
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.