Reputation: 8888
In my content tree, I have items that contains sub items. The sub items are where the content for the parent item are.
E.g.
Article container <---- only this item is navigable to the user
|
|- Text block = "foo foo foo foo"
|- Image = "foo.jpg"
|- Text block = "foo foo foo"
When the user navigates my website, they will never find a link to any of the sub items. They will only ever get to the url for "Article container", which has a presentation such that all of the sub items are displayed on the page.
In a regular indexing scenario, all 3 sub items would match the query "foo" and be returned in the results. I want to create a Sitecore 7 index purely for website search which will return the parent item ("Article container") for a search query for the term "foo". I don't want any of the sub items to be returned in the query results.
Is this possible to do with some combination of computed fields, inbound or outbound index filters (or something else I haven't heard about)?
Or will I have to parse the output and resolve the parent item before displaying it to the user?
EDIT
@martindavies' answer is good, but I was wondering if there's a way to do the indexing "upstream" where you index the child item and store it's content against the parent item in the index, rather than "downstream" where you index the parent and store all child content in the parent's index entry. The reason for this is so that any edits to the child items will be re-indexed automatically without having to manually trigger a re-index of the parent article.
Upvotes: 1
Views: 1562
Reputation: 4774
IMHO the easiest way to achieve this is to have all of your page items inherit from a common base template, and then to create an index that only includes items that inherit from said base template.
Think about Sitecore from a higher level, i.e. don't think about indexing based on field values (which can always be changed), but rather think about indexing based on the type of item that you want.
Update
Note: In my original answer (above), I slightly misunderstood the goal you were trying to achieve with the index. The above would hold true if you are looking to just index the items representing the pages that you would go to.
IMHO, for your situation the best thing to do would be to actually run the index as you normally would (which would index the child items as hitting points) but to then use URL Rewriting/a custom Rewrite Processor to direct all requests to the children of an article item to the article item instead.
Upvotes: 0
Reputation: 4456
eYou could create a computed field called 'childitemcontent' that does the following during the indexing process:
Here's a good article to get you started:
SITECORE 7: COMPUTED INDEX FIELDS
I actually asked something very similar a while back (pre Sitecore 7) and was directed to a video which was quite helpful:
Sitecore - Indexing data from presentation components with non-context datasources
The good thing about that approach is that it doesn't rely on the referenced items being children of the page item. (FWIW I'm not a fan of storing page content items under a page. I prefer to keep them outside the content tree).
Upvotes: 5