SharpPS.Sitecore.ContentSearch.XA 1.2.7

SXA Search API

This module does not add a new HTTP endpoint. It plugs into two existing things that back Sitecore XA's search UI:

1. SXA's native Web API controller, Sitecore.XA.Feature.Search.Controllers.SearchController.
2. The base SharpPS.Sitecore.ContentSearch renderer/controller (SPContentSearchController, area SPSearch), reused here with SXA's ContentPage index model and facet items.

1. Native SXA endpoint (reference)

Routed by SXA per-site as {site-virtual-folder}/sxa/{controller}/{action}, e.g. /sxa/search/results. Web API (not MVC) — query string only, JSON only.

Query string parameters:

Facet filter widgets (checklist/range/radius/etc.) append their own query params which SearchService.GetQuery reads independently via Context.Request.QueryString — not part of the model binders above.

Response shapes:

GetSuggestions behavior depends on the search:define appSetting: on Lucene it's just GetResults with each result's rendered Html returned as a Suggestion.Term; on Solr it calls the native Solr Suggest handler (sxaSuggester, top 5) for real prefix suggestions.

2. What this module changes on the native SXA endpoint

SearchController.GetResults / GetFacets both call Sitecore.XA.Foundation.Search.Services.ISearchService.GetQuery(...), which depends on two extension seams — this module replaces/extends both:

BucketableIndexResolver adds two behaviors on top of stock SXA index resolution:

Boosting rule conditions — IBoostingService.BoostQuery (called from GetQuery) evaluates the site's Boosting rules; these two new conditions become available in the Boosting rule editor on a Search Scope item:

Net effect: both take effect transparently on every call to /sxa/search/results and /sxa/search/facets — no controller changes needed.

Rule editor items (as shipped in the package)

Both conditions ship as items under /sitecore/system/Settings/Rules/Definitions/Elements/SXA/ in SharpPS.Sitecore.ContentSearch/App_Data/Items/SP Content Search-2.1.0.zip (package → items/master/sitecore/system/Settings/Rules/Definitions/Elements/SXA/...). This is the exact text an author sees in the Boosting rule set editor, with each [macro] bound to the condition class's property of the same name:

Macro sources (TreeList roots referenced in the rule text field):

SearchXADefinition.Pipeline = "SP SXA Content Search" also has a matching picklist item — /sitecore/system/Modules/SP Content Search/Pipelines/SP SXA Content Search/{9C27C599-50FC-4EAF-B018-48CC80F6ED48} — the source list for the Pipeline droptree field on the datasource template (see below).

3. This module's own search rendering ("SP SXA Content Search")

Separate from the above: SharpPS.Sitecore.ContentSearch.XA also overlays the base SharpPS.Sitecore.ContentSearch generic search rendering (see that project's own docs/README.md for setup — duplicate Rendering/Feature/SP Content Search, matching datasource + variants) so its datasource can target SXA buckets/facets.

This gives you an alternative to SXA's JS search widgets: a server-rendered (or ?renderJson=1 / Accept: application/json) MVC rendering, driven entirely by a Sitecore datasource item, that runs against the same SXA index/scopes/facets configuration.

Datasource template

Ships in the same package as /sitecore/templates/Modules/SP Content Search/Definition/SXA Search Definition ({80684200-82FC-49DB-A026-4A6281EB4023}), based on the core Search Definition template ({EF096545-2592-4EC8-B200-1910EE93321E}) plus an XA-only Options section:

Standard Values preset on this template already sets:

— so a datasource created from this template is wired to the XA pipeline group and ContentPage index model out of the box; you only need to fill in Root/Templates/ Facets/ScopesIDs and the rest of the base Search Definition fields.

Setup