Add Search API Exclude Entity module to GovCMS

[marblegravy]

** Please provide the Drupal.org URL for the module
https://www.drupal.org/project/search_api_exclude_entity

** What value does this module/package add to GovCMS?
This module provides content editors and site builders with sophisticated, granular control over which entities appear in Search API results. It enables per-entity exclusion from search indexing through a configurable custom field type, allowing organizations to manage search visibility for draft content, administrative pages, placeholder content, or any entities that should remain published but hidden from search results.
The field-based approach offers flexibility to have different exclusion settings for different search indexes on the same site, making it ideal for complex search architectures.

** Is the module Drupal 11 compatible?
Yes. Version 3.0.0 (released January 6, 2025) explicitly supports Drupal 10 and Drupal 11 (^10 || ^11). This is the latest stable release and represents active, current development for modern Drupal versions.

** Please provide a brief outline of what this module does.
Search API Exclude Entity is the successor to the Drupal 7 Apache Solr Node Exclude module.
It provides a custom field type, widget, and formatter that allows editors to exclude individual entities (nodes, media, taxonomy terms, etc.) from Search API indexes.
Unlike simpler hook-based approaches, it uses a dedicated field that can be added to any entity bundle, with the exclusion processing handled by a configurable Search API processor plugin.
This architecture provides Views integration out-of-the-box, allows multiple exclude fields per bundle for different search systems, and enables field-level configuration of labels, descriptions, and positioning per entity type.

** Who does this module benefit:
[x] end users (indirectly, through cleaner, more relevant search results)
[x] content editors (primary beneficiaries - direct control over search visibility per entity)
[x] site builders (configurable per entity type/bundle, multiple field support for complex architectures)
[ ] themers
[x] developers (provides processor plugin API and Views integration)

** How could you provide/replicate the functionality of this module using alternative methods, eg in your theme?
Alternative approaches include:

1. Custom Search API processor plugin that filters based on boolean field values (not possible in GovCMS?)
2. Using the simpler Search API Exclude module (hook-based, less flexible but easier setup)
3. Custom code implementing hook_search_api_query_alter() to exclude entities (not possible in GovCMS?)
4. Node access controls (though this affects all access, not just search - difficult or not possible in GovCMS?)

However, none of these alternatives provide the same combination of flexibility, field-based configuration, Views integration, and multi-index support that Search API Exclude Entity offers. The module's custom field type approach is more robust and maintainable than alternatives.

** If this module styles or alters HTML or JavaScript output, can the functionality be provided via the theme? What alternatives have you considered.
This module does not alter HTML or JavaScript output. It operates entirely at the Search API indexing/processing layer, controlling which entities get indexed before they ever reach search results. Theme-based solutions would be inappropriate and ineffective for this functionality, as the filtering must occur during index building, not during page rendering.

** What is the maintenance and support status of the module. Describe the issue queue activity.
The module is actively maintained with recent significant updates. Version 3.0.0 was released on January 6, 2025, adding Drupal 11 support and resolving 8 issues. The module is co-maintained by beltofte (JAKALA, formerly FFW) and smustgrave (Mobomo), with smustgrave added as co-maintainer in January 2023 specifically to ensure ongoing D10/D11 support. The module is covered by Drupal's security advisory policy. The issue queue shows healthy activity with 2 currently open issues and 47 total issues resolved. Recent development includes work on metatag integration and field value-based exclusion features. With 11,966 active installations, the module has strong community adoption and trust.

** What permissions are needed to utilise the module (and are any new permissions provided by the module)?
The module provides the "administer search api exclude entity" permission for configuring the Search API processor settings. For end users, the module respects Drupal's standard field-level permissions system - users need appropriate entity edit permissions to modify the exclude field value on individual entities. Standard content editing permissions (e.g., "edit own article content" or "edit any article content") control access to the exclude checkbox. Site builders can configure field access using Drupal core's field UI or contributed modules like Field Permissions if more granular control is needed.

** Does the module modify the database structure and/or store additional metadata on nodes or other entities? If so, why? What are the risks for future updates?
Yes, the module stores exclusion data using Drupal's standard field system through a custom field type. When configured, it adds field tables to store boolean exclusion values per entity. This is necessary because the module uses a proper field-based architecture rather than hard-coded fields, enabling multiple exclude fields per bundle and full field API integration. The risks for future updates are minimal because:

• Uses Drupal core's field storage API (standard, stable, well-maintained)
• Field data is managed through normal field lifecycle (update, delete, migrate)
• If the module is removed, fields can be safely deleted through Drupal's standard field deletion procedures
• The custom field type follows Drupal's field plugin architecture, ensuring upgrade path compatibility

** Is the module designed to capture anonymous user data?
No. This module does not capture, store, or process any user data. It only controls which entities are included in search indexes based on field values set by content editors.

** Is the output of the module typically fully cacheable? Would the inclusion of this module potentially render pages uncacheable.
Yes, output is fully cacheable. This module operates exclusively at the search indexing layer, not during page rendering or request handling. The exclusion filtering happens during index creation and updates (background processes), not during user-facing page requests. All pages remain fully cacheable as the module has zero impact on cache contexts, tags, or max-age. There is no performance impact on page delivery.

** What is your assessment of the quality of this module, the contribution history of the module's maintainers, and the uptake of the module within the Drupal community?
This is a high-quality, well-maintained module with strong community standing.

Quality & Architecture: The module demonstrates excellent architectural decisions by using a custom field type rather than hard-coded fields, providing proper processor plugins, and offering Views integration. The field-based approach is more flexible and maintainable than hook-based alternatives.

Maintainer History: Originally created by beltofte (JAKALA/FFW), the module gained co-maintainer smustgrave (Mobomo) in 2023 specifically for D10/D11 readiness. Smustgrave maintains 20+ modules and is a Drupal core subsystem maintainer, bringing significant expertise. This dual-maintainer model with organizational backing (JAKALA and Mobomo) provides sustainability.

Community Uptake: With 11,966 reported installations, this is one of the most widely-used Search API extensions. It is covered by Drupal's security advisory policy, indicating it meets security standards. The module has been stable since 2019 (version 1.0.0) and has successfully evolved through Drupal 9, 10, and now 11.

Recent Development: The January 2025 release of 3.0.0 demonstrates active maintenance and forward-looking development. Recent issue queue activity shows work on advanced features like metatag integration and field value-based exclusion.

Comparison to Alternatives: This is the recommended solution over the simpler "Search API Exclude" module for any site requiring flexibility, Views integration, or multiple search indexes.

** Additional information
Implementation Considerations:

• Requires Search API to be installed and configured
• Uses a processor plugin that must be enabled in Search API index settings (admin/config/search/search-api/index/[index]/processors)
• Fields must be added to entity bundles where exclusion is needed
• Supports any entity type with bundles (nodes, media, taxonomy, custom entities)
• Provides Views field/filter integration for bulk management
• Can support multiple exclude fields per bundle for different search indexes

Related Modules: Works well with Search API, Search API Solr, and can integrate with Metatag module for additional exclusion scenarios.

[jackwrfuller]

@marblegravy thank you for your submission!

We will discuss this internally, but in the meantime if people have any cases of what they're doing or would like to do, feel free to add it in this thread.