You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement related to a problem? Please describe.
Bucket aggregations in Elasticsearch cannot retrieve more than one field at a time, this is a known limitation. Because of this, when dealing with custom facet selections, usually a developer needs to query the database for extra information about each facet to be able to reconstruct the UI filters. Usually this means either querying for all terms in a given taxonomy (as we do for the Facet Widget) or querying for each term individually.
This requires facets to be processed on the server and involve the WordPress database, adding server load, and ultimately leading to poor load times when dealing with large numbers of aggregations.
Describe the solution you'd like
The ideal scenario for client-side search is that all the elements needed to rebuild the UI be present in the Elasticsearch response. #2071 addresses this by creating a facet field of type keyword in the mapping of term objects attached to post objects. The new field contains a non-analyzed text representation of the term object in JSON form.
The PR also introduces a new filter ep_facet_use_field, with a default value of slug, allowing developers to choose from one of the available fields in any term object: slug (default), term_id, name, parent, term_taxonomy_id, term_order, and the new field introduced: facet.
The new filter gives developers the freedom to retrieve aggregations based on the field that is most convenient to their needs.
The text was updated successfully, but these errors were encountered:
Is your enhancement related to a problem? Please describe.
Bucket aggregations in Elasticsearch cannot retrieve more than one field at a time, this is a known limitation. Because of this, when dealing with custom facet selections, usually a developer needs to query the database for extra information about each facet to be able to reconstruct the UI filters. Usually this means either querying for all terms in a given taxonomy (as we do for the Facet Widget) or querying for each term individually.
This requires facets to be processed on the server and involve the WordPress database, adding server load, and ultimately leading to poor load times when dealing with large numbers of aggregations.
Describe the solution you'd like
The ideal scenario for client-side search is that all the elements needed to rebuild the UI be present in the Elasticsearch response. #2071 addresses this by creating a
facet
field of typekeyword
in the mapping of term objects attached to post objects. The new field contains a non-analyzed text representation of the term object in JSON form.The PR also introduces a new filter
ep_facet_use_field
, with a default value ofslug
, allowing developers to choose from one of the available fields in any term object: slug (default), term_id, name, parent, term_taxonomy_id, term_order, and the new field introduced: facet.The new filter gives developers the freedom to retrieve aggregations based on the field that is most convenient to their needs.
The text was updated successfully, but these errors were encountered: