Search index for complex page type

Tom Troughton asked on April 27, 2015 12:12

I'm modelling a flexible page type which will have some core fields, but then needs to allow editors to add a number of other groups of fields. These will display as tabs of differing content. To achieve this I've created these field groups as 'sub' page types which can be added beneath the main page. These sub page types won't ever be displayed as pages themselves.

My challenge is to ensure the content of these sub pages is indexed as content of their parent page, rather than as pages in their own right. Since they're not actually pages I don't want the search to return these sub-pages themselves. I'm assuming I have 2 options:

  1. Handle an event fired when each page is indexed and ensure I manipulate the indexing as required. I'm not sure if such an even exists or if this is even feasible.
  2. Write a custom index

Can you advise please? Is there another alternative? If writing a custom index is the answer, how can I ensure that the index is re-built when affected pages are published? This isn't clear from the documentation.

Thanks.

Recent Answers


Brenden Kehren answered on April 27, 2015 13:31

I've done the same approach on a few sites. In most cases using a page index works but when I needed more specific results, I was able to fine tune the page crawlers index with a combination of the search settings on each of the page types and how the results were displayed. For me the key was to create that crawler index and include ONLY the page types needed. Then for each of the "content" sub page types, remove the defaults Kentico suggests and ONLY include the fields you want to search/index.

This should help you get pretty close to what you're looking for without having to write any code.

1 votesVote for this answer Mark as a Correct answer

Tom Troughton answered on April 27, 2015 14:00

Brenden, thanks for the quick response. Would you be kind enough to provide a bit more detail? My understanding of the page crawler type of index is that it's just crawling HTML and doesn't pay attention to the page type's Search Fields tab. Your comment "ONLY include the fields you want to search/index" suggests otherwise?

My concern about using Page Crawler is that there isn't much control over how the analyser identifies the key content of a page. For example, distinguishing between content that is part of that page type and content being displayed from other pages. So I had hoped there might be a way using a Pages type of index, maybe in code by incorporating fields from a child page...

P.S. I'm not at all averse to writing code :)

0 votesVote for this answer Mark as a Correct answer

Bill Tran answered on April 28, 2015 21:02 (last edited on April 28, 2015 21:10)

You would have to create your own index or customize the results somehow.

You can modify /CMSModules/SmartSearch/Controls/SearchResults.ascx to customize your result. There is a dataset that contains all the values for your search results, you'll need to remove all the sub pages from the dataset and add the necessary parent pages into the dataset. I haven't tried this approach before, so you'll have to tell me if it works.

1) Create two indexes, one that is normal and the other for the sub pages
2) Add 2 search results onto the page, one for each index. Make sure the sub pages search results is executed first.
3) set the sub pages search results to display:none or visible=false in code behind but only after code executes.
4) When the code executes for the sub page search results, store the values of all the unique parent node ids for the sub pages, and pass it to the normal search results control.
5) When the code executes for the normal search results, retrieve all the content for those ids captured in (4), and add them to the data set in the search results control.
6) Wait and see.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.