Basic (simple keyword) search currently builds a plain, hand-assembled boolean query against a single combined search field, using Solr's standard query parser, with no highlighting of matched text. There should be a configurable option to switch basic search to Solr's EDISMAX query parser, with admin-configurable per-field weighting, and to show a tooltip with a highlighted excerpt of where a search matched.
This must not require reindexing existing content, and field weighting must be configurable the same way other admin-editable field lists already are in this project — as plain field names in configuration, not hardcoded — so that fields introduced by descriptive-metadata configurations outside this codebase can also participate.
Acceptance Criteria
Notes
The field basic search currently targets is a combined field built by copying every other field's content into it, and it isn't stored. Solr's default highlighter needs a field to be stored in order to produce a highlight from it, and making that combined field stored would require reindexing everything already indexed — so this combined field is not a valid target for highlighting or for the weighted field list; only fields that are already stored today qualify.
This project already indexes some descriptive-metadata fields through externally configurable transforms, where the field name is decided outside this codebase and doesn't need to be known in advance for the field to be indexed and usable. The relevance-weighting and highlighting configuration for this feature should follow the same principle: a plain, admin-editable list of field names (with an optional weight), not a fixed list built into the code — this project already has more than one example of exactly this kind of configuration for other purposes, and this should follow the same shape rather than inventing a new one.
Open Questions
- Should the new option default to on or off for a fresh install?
- What should the default set of weighted/highlighted fields be, before any admin customizes it?
- Should there be a startup or query-time check that warns when a configured highlight field isn't actually stored, given this project can't know in advance about every field an external configuration might introduce?
Out of Scope
- Any change to advanced/field-specific search's query parser or behavior, regardless of this option's state.
- Any reindex of existing content, under any circumstance.
- Additional relevance-tuning parameters (phrase boosting, minimum-should-match, tie-breaker) beyond per-field weighting itself.
- Any index-time weighting/boost mechanism — weighting only applies at query time.
Basic (simple keyword) search currently builds a plain, hand-assembled boolean query against a single combined search field, using Solr's standard query parser, with no highlighting of matched text. There should be a configurable option to switch basic search to Solr's EDISMAX query parser, with admin-configurable per-field weighting, and to show a tooltip with a highlighted excerpt of where a search matched.
This must not require reindexing existing content, and field weighting must be configurable the same way other admin-editable field lists already are in this project — as plain field names in configuration, not hardcoded — so that fields introduced by descriptive-metadata configurations outside this codebase can also participate.
Acceptance Criteria
qf) and the fields used for highlighting are both configurable, independently of each other, as plain field names — including fields that this project's own code has no built-in knowledge of.Notes
The field basic search currently targets is a combined field built by copying every other field's content into it, and it isn't stored. Solr's default highlighter needs a field to be stored in order to produce a highlight from it, and making that combined field stored would require reindexing everything already indexed — so this combined field is not a valid target for highlighting or for the weighted field list; only fields that are already stored today qualify.
This project already indexes some descriptive-metadata fields through externally configurable transforms, where the field name is decided outside this codebase and doesn't need to be known in advance for the field to be indexed and usable. The relevance-weighting and highlighting configuration for this feature should follow the same principle: a plain, admin-editable list of field names (with an optional weight), not a fixed list built into the code — this project already has more than one example of exactly this kind of configuration for other purposes, and this should follow the same shape rather than inventing a new one.
Open Questions
Out of Scope