I’m doing a query and gets the results back listing the contentyypes that matches.
But is it possible to query for parts to being able to give more detailed results back…
As an example…
A user queries for “logo” and of course you get a hit on the “Downloads” page among others…
But the downloads page is very long and contains lots of downloadable assets for different purposes. So instead of just sending them to the page and make them scroll and search on the initial site, I would like to provide links to anchors (based on parts) on the “Downloads” page with the parts that actually got the hit.
Visually in Lynx I guess a single hit would look something like this:
`
** Nedlastinger **
Logotyper til trykk
Logotyper til digitalt
Animert logo til video
`
This isn’t really like the highlight feature of ElasticSearch, since I don’t want to highlight an actual field, rather do some aggregations / scoring on hits to get a new score to define what part that actually contains the data.
Any ideas? I could of course instead of using parts create a section contenttype that lists all sub contents instead of using parts.
But since they aint supposed to be preview/viewed by themself wouldnt it introduce problems with the preview window and perhaps make it more complex with layouts?
Need a better explanation to understand the issue… However, I would like to point out parts may contain stuff that is not indexed, so there is not neccessarily a 1:1 relationship on seach and parts on a page… Also consider dropping “landing pages” from your search alltogether.
Hmmm, hard to explain… but I’ll give it another go.
We are making a page, that doesn’t consist of dedicated content like articles and products.
I would rather describe it as 6-7 really long pages with structured sections, each with little text and information and linking to downloadable files.
These sections are built up from one or several parts and therefore I would like to be able to get some more “context” from the search result on what actually gave it a hit.
Just so it’s mentioned: Might be worth trying Google Custom Search. It has a price-tag after a certain number of searches, but it does an actual indexing of all pages and would solve the problem today. https://market.enonic.com/vendors/enonic/com.enonic.app.google.cse
I’ll let Thomas continue the discussion about built-in part indexing in XP.
Yes, that may result in better search hits overall, but would probably make it harder to query for details.
When you use a content selector to select a file, are the attributes/meta-data on that file indexed as part of the content when you do a search?
Since it in the data model just saves the ID, it would be interesting to know if I will get a hit on my “Page” that have a file selected with some text/metadata fields that matches the query or is the search somewhat basic and just perform LIKE / AND / OR operations on TextArea and TextLine fields in the page document?
Or is it implemented with something like Elastic Search parent-child relations?
I’ve just concluded with that I either have to go for Google Custom Search as @bwe suggests as a quick fix to get descent search results.
And in the long run I’ll look more into creating a “action interceptor” to hook into admin events and build a pure elastic search index that I can build custom index for each contenttype.