Per Magne Skuseth
Jan 14, 2014
  3825
(6 votes)

Unified search and culture specific MediaData

I was creating a search page for a customer using EPiServer Find. As they have plenty of page types, I decided to use unified search. However, they also have a lot of documents (PDFs) that should also be searchable .No problem, unified search takes care of that out of the box. But this site also had several languages, and since MediaData in EPiServer 7.5 is not localizable, I had to write some code as Find has no way of knowing which language the different files should be part of. Here is what I did:
   
First, a string property should be added to a MediaData base class, which will store the language ID.

[ContentType(GUID = "EE3BD195-7CB0-4756-AB5F-E5E223CD9820")]
public class GenericMedia : MediaData
{
    [SelectOne(SelectionFactoryType = typeof(LanguageSelectionFactory))]
    public virtual string LanguageBranch { get; set; }
}


To make it more editor friendly,  the SelectOne attribute could be used on the property(Check out Linus’s blog post for more information regarding the SelectOne attribute). In this case it uses a selection factory that returns all available languages on the site:

public class LanguageSelectionFactory : ISelectionFactory
{
    public IEnumerable<ISelectItem> GetSelections(ExtendedMetadata metadata)
    {
        // Get all the languages branches
        IList<LanguageBranch> languageBranches =
            ServiceLocator.Current.GetInstance<ILanguageBranchRepository>().ListEnabled();
        foreach (var branch in languageBranches)
        {
            // and then return them as SelectItem
            yield return new SelectItem()
            {
                Text = branch.Name,
                Value = branch.LanguageID
            };
        }
        // finally, return an option which will be used to make the MediaData searchable across all languages
        yield return new SelectItem()
        {
            Text = "All languages",
            Value = null
        };
    }
}

SNAGHTML708c224

Neato!

Then, an extension method that will use the language property and do the appropriate filtering. The extension method should only filter non-localizable items, so that it will not affect pages.

public static FilterExpression<ISearchContent> ApplyMediaLanguageFilter(this ISearchContent content)
{
    var currentLanguage = ContentLanguage.PreferredCulture.Name;
    return new FilterExpression<ISearchContent>(x => x.MatchTypeHierarchy(typeof(ILocalizable))
                                         | ((GenericMedia)x).LanguageBranch.Match(currentLanguage) 
                                         | !((GenericMedia)x).LanguageBranch.Exists());
}


And finally, use the extension method in the Find query

var query = SearchClient.Instance
    .UnifiedSearchFor(q)
    .Filter(x => x.ApplyMediaLanguageFilter())

That’s it! Culture specific file search is now working. Setting the languages property on the files will be required though.

 

Related super quick tip:In this case I also saw the need to remove image files from the result

.Filter(x => !x.MatchTypeHierarchy(typeof(ImageData)))
Jan 14, 2014

Comments

Jan 14, 2014 11:44 PM

Nice one.

I prefer to search over all languages though, but then maybe have filters for languages instead. I mean, it's more important to find what your're searching for, then get results it in the same language as the visiting page.

Per Magne Skuseth
Per Magne Skuseth Jan 15, 2014 05:58 AM

I guess that depends on the content and the customer, Johan. But I do agree that having filters for languages is preferable in a lot of cases. With that in mind,the extension could easily be modified to accept a language parameter instead of using the current language

Marcus Granström
Marcus Granström Jan 15, 2014 09:23 AM

Nice post. Thanks for sharing.

Sven-Erik Jonsson
Sven-Erik Jonsson Feb 10, 2015 03:31 PM

Don't really know if this has been added later, but EPiServer contains a SelectionFactory that almost replicates this identically

inside EPiServer.Cms.Shell.UI.ObjectEditing.EditorDescriptors.SelectionFactories.
Instead of creating your own "LanguageSelectionFactory", for reduced type ambiguity, I would recommend overriding the existing and

adding an "all languages" option like below.

public override IEnumerable GetSelections(ExtendedMetadata metadata)
{
yield return new SelectItem() { Text = "All languages", Value = null };
var selections = base.GetSelections(metadata);
if (selections == null) yield break;
foreach (var selection in selections)
{
yield return selection;
}
}

Of course naming it something different than the existing one.

Please login to comment.
Latest blogs
Optimizely SendGrid SMTP host is deprecated

SendGrid is a services for sending email that is included in Optimizely DXP. Previously smtp.episerver.net was the recommended SMTP server to use,...

Tomas Hensrud Gulla | Dec 4, 2022 | Syndicated blog

Hosting Optimizely CMS 12 on Docker Engine

Since Optimizely CMS can now be deployed as a Docker container, here is a demonstration of building, running and scaling an Optimizely CMS 12 site ...

Stefan Holm Olsen | Dec 4, 2022 | Syndicated blog

How to use CacheTagHelper with content areas in Optimizely CMS 12

I might be going out on a limb here - if you have a better solution, feel very free to share it!  Upgrading your Optimizely web application from .N...

Andreas J | Dec 2, 2022

The 1001st Piece in your 1000 Piece Puzzle: .NET Default Interface Functions

I was recently working with a client who wanted a reasonably large subsystem added to Optimizely that would add automated management to their...

Greg J | Nov 28, 2022 | Syndicated blog