On a site I’m currently building on XP, we have a bunch of ordinary content types, like articles and offices. They are indexed automatically, and thus easily searchable (queryable).
However, we also have quite a few “single” pages where it seems a bit over the top to create content types for each one of them. Instead they are built with an empty landing page and filled using parts. Some are generic parts where the content is in the part config, and some parts where the content simply comes from the html (via the controller/services).
These single landing pages are also important to us content-wise, and we’d like them to be searchable (including the content from the parts) and show up in our site search, ideally giving a hit on the landing page which has the part with the matching content.
Does anyone have a sensible approach to solve this?
I know that using google site search would solve the problem, but I want to find a local solution that we can present to the user in a better and more customized way.
Do people create tons of content types to facilitate these kinds of single pages? To me that seems to create quite a lot of (unnecessary?) content types that content editors would need to relate to, especially since there’s to my knowledge is no way to hide certain content types, pages or parts to people with different roles.
The answer is yes, and no…
Only textcomponents are indexed as of today, and included in the _alltext field. If you study how data are stored using the repoXplorer app, you will see the indexing instructions. In order to index parts that are placed at “random” places in the structure special indexing instructions need to be created and stored with the content.
To automate this, we would further have to provide configuration options for part config’s, as you would most likely not want to index everything as _alltext either.
Wouldn’t simply honoring the true param in any part config be a good candidate for a solution on how to indicate that you want the content to be indexed?
Of course, it would need some (or perhaps a lot) of coding in the XP backend for storing the content and making it retrievable. Perhaps creating a partData object similar to the x object in the content blob? I guess there could be side effects to such an approach, but I leave that to you who know more about the storage and indexing inner workings.
This would really lift the possibilities in XP, lifting parts to be «1st class citizens».
He probably means the <indexed>true</indexed> specification that is used in our demos and documentation. However, @nerdegutt, that parameter is not used. But guess you knew that based on your suggestion =)
Hmm… Is that still alive in the docs? This attribute essentially refers to indexing of each property, and they are all indexed by default. What you are looking for is indexing in the “alltext” property I assume?
If simply adding the <indexed>true</indexed> to any part item would have it indexed in the parent content alltext field that would be a great improvement already. My main concern is making the pages with only part content searchable at all.
It is slightly more complex, as we would like to be consistent across schemas. I.e. today text, textarea and htmlarea fields in content-type schemas are automatically included in the alltext field to my knowledge. We would need to choose if this should apply also for the other fields i.e. “application config” as well as the “components”