Custom Search Index And Possible Bug

Posted by Community Admin on 04-Aug-2018 20:25

Custom Search Index And Possible Bug

All Replies

Posted by Community Admin on 09-May-2013 00:00

I have created a custom search index to search blog posts.

In the custom fields I have entered the following - "Categories, Tags"

The attached screenshot shows an example blog post with respect to the categories and tags recorded against the blog post.

However when debugging in Visual Studio the search results is showing the following data against the blog post in the search index

City Breaks,shopping,stopover,Melbourne,Australia,stopovers,Australia,


I appreciate that tags are not supposed to be able to be indexed, however was experimenting to see if any data would be included in the search results.

However are you able to explain why the tag values are actually being indexed in the Categories field of the search index ? This is an unexpected outcome.

Thanks, Nigel

Posted by Community Admin on 09-May-2013 00:00

Just to clarify - the fact tags are indexed in the categories is possibly a good thing... 
So more wanted to know if this was a bug or an intended outcome - hate to code for the current situation, only to have it changed in later releases. :-) 


Posted by Community Admin on 03-Jun-2013 00:00

Tags and categories are both the same thing in Sitefinity: taxonomies. The only difference between them is one is hierarchical and the other isn't. Both are stored in the same field, and differentiated at display time if I remember right. Which is why you see them coming back this way.

Now, what's MORE interesting to me is that Categories DIDN'T come back as (Collection) as I think it should have here... which implies there is an outbound pipe somewhere actually processing those, which is very interesting...

So anyway, to your issue, we do something similar, although we use tags for a different purpose: filtering. So we actually store tags based on ID, and then have a custom search results widget that accepts a filtering query string parameter to filter results by. But this should be adaptable for your use.

First, you need a custom outbound pipe to process the tags collection:

    /// <summary>
    /// Tag Search Index Outbound Pipe Class.
    /// </summary>
    /// <remarks></remarks>
    public class TagSearchIndexOutboundPipe : SearchIndexOutboundPipe
        /// <summary>
        /// Gets the converted items for mapping.
        /// </summary>
        /// <param name="wrapperObject">The wrapper object.</param>
        /// <returns>List of IDocuments.</returns>
        public override IEnumerable<IDocument> GetConvertedItemsForMapping(WrapperObject wrapperObject)
            if (wrapperObject.HasProperty("Tags"))
                var tags = wrapperObject.GetProperty("Tags") as IList<Guid>;
                if (tags != null)
                    var newValue = "";

                    foreach (var tag in tags)
                        if (newValue != "")
                            newValue += ",";
                        newValue += tag;

                    wrapperObject.SetProperty("Tags", newValue); // Set the new value to Tags property

            return base.GetConvertedItemsForMapping(wrapperObject);

And then you need to register it. We actually have all this rolled into a module that registers on app start, but I think you can do the same registration in the Global.asax Application_Start:

            PublishingSystemFactory.RegisterPipe(SearchIndexOutboundPipe.PipeName, typeof(TagSearchIndexOutboundPipe));

Note that what this does is make sure that when an index action occurs (publish, reindex, etc.) it takes the "Tags" property (which is a collection) and then builds a comma delimited list of tag IDs, and makes sure THAT is the value that gets indexed for the "Tags" field instead of it incorrectly trying to cast the collection and you just ending up with (Collection).

If you want the actual tag names to appear here, you'll have to do a lookup on each ID and add that name instead.

This thread is closed