Search API Parent Fields

Search API Parent Fields

Summary

Search API Parent Fields adds a "Parent entity fields" processor to Search API for indexes that index Paragraph items directly (an
entity:paragraph datasource). It lets you index fields from the entity that hosts a Paragraph — its parent — as if they were fields of
the Paragraph itself.

The problem it solves

Paragraph items are composition building blocks: they rarely carry, on their own, all the information you'd want to search or facet on.A "session" or "programme edition" paragraph, for example, typically needs data that only exists on the node it belongs to — the event's title, its taxonomy terms, its dates, a related image. Out of the box, Search API has no built-in way to reach "up" from a Paragraph toits host entity and pull fields from there into the same index item. This module fills that gap with a single, focused processor.

How it works

1. Enable the Parent entity fields processor on your Search API index (Index → Processors tab). 2. Configure it: select the entity type your Paragraphs are normally attached to (defaults to node). This setting only controls which fields are offered in the field-picker tree in the admin UI — at index time, the actual parent entity is always read live from the Paragraph's own getParentEntity(), whatever its real type turns out to be. This means a single Paragraph bundle used under different parent entity types will still resolve correctly at runtime; the configuration is purely a UI convenience for browsing available fields. 3. In "Add fields", browse into Parent entity fields and pick whichever field(s) you need. The resulting property path looks like parent_field:, and can be nested further through entity references, e.g.:
- parent_field:body
- parent_field:field_topic:entity:name
- parent_field:field_image:entity:field_media_image:entity:uri:url

Internally, the processor watches for any index field whose property path starts with parent_field:, resolves the current item's Paragraph parent entity, and uses Search API's own FieldsHelper::extractFields() to pull the requested values from it — the same mechanism Search API itself uses for ordinary entity reference traversal, so nested/multi-value extraction, language handling, etc. all behave exactly as they would for any other field.

Features

- Works with any content entity type as the parent (not hardcoded to node), configurable per processor instance via a simple select in the processor settings form.
- Full support for nested property paths through entity references, exactly like Search API's native field browser.
- supportsIndex() restricts the processor to indexes that actually have a Paragraph datasource, so it doesn't clutter the processor list on indexes where it wouldn't apply.
- No custom services, no schema surprises: configuration is a single parent_entity_type key with a proper config/schema definition.
- Items are simply skipped (parent fields left empty) when a given Paragraph has no parent at index time — no fatal errors.

Requirements

- Search API
- Paragraphs

Configuration

1. Index → your index → Processors tab → enable Parent entity fiel → click "Configure" to pick the parent entity type → save.
2. Go to Fields and add whichever Parent entity fields → ... properties you need.

Notes / limitations

- The module currently targets Paragraph items specifically (via \Drupal\paragraphs\ParagraphInterface::getParentEntity()); it isn't a generic "any entity with a parent" solution.
- If a site uses the same Paragraph bundle under genuinely different parent entity types on the same index, the field browser will only show the configured type's field list, but extraction at index time is still correct for whichever parent type each item actually has — you just won't see that other type's fields offered for selection.