Create a configurable search api processor for XB data

Created on 24 October 2024, about 2 months ago

Overview

🌱 [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active demonstrates a requirement to be able to use XB data in scenarios other than rendering content.
One such use case is for seach

Proposed resolution

At this point it looks like Search API is going to be part of Drupal CMS. In addition the search module is slated for removal from core 🌱 [Policy] Move Search module to contrib Active .

Create a proof of concept configurable search api processor that allows extracting data from component properties for the sake of indexing.

For example, Search API ships with a 'Rendered entity' processor plugin that lets you configure a view mode to use for each entity-type bundle. During indexing this plugin renders the entity and the results can be used in a search API index. This is typically combined with something like a strip HTML processor and one that weights e.g. h2/h3 higher. This is however not very precise, if you have a common footer component on every page those elements end up in the index for every page.

The proposed solution should provide a list of enabled component config objects and a checkbox for each of their props.
For example, you might have a card component with fields for image, title and teaser text.

You might decide that you want a search api field (in the index) that contains the contents of any card titles. To achieve this you would add a field using this plugin, and configure it so the card component's title field was indexexed.

User interface changes

📌 Task
Status

Active

Version

0.0

Component

Data model

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @larowlan
  • First commit to issue fork.
  • Pipeline finished with Failed
    4 days ago
    Total: 714s
    #372592
  • 🇬🇧United Kingdom catch

    For example, Search API ships with a 'Rendered entity' processor plugin that lets you configure a view mode to use for each entity-type bundle. During indexing this plugin renders the entity and the results can be used in a search API index. This is typically combined with something like a strip HTML processor and one that weights e.g. h2/h3 higher. This is however not very precise, if you have a common footer component on every page those elements end up in the index for every page.

    The proposed solution should provide a list of enabled component config objects and a checkbox for each of their props.
    For example, you might have a card component with fields for image, title and teaser text.

    It's not clear to me how this would interact with non-XB field data on the entity (title, intro, hero image etc.)

    Let's assume that those entity-level fields are configured within an XB layout, then does the processor also handle how those are rendered for search indexing, or do you need to set up both a search view mode and this processor side by side - one for the entity-level fields, and one for the XB props?

Production build 0.71.5 2024