Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
The node search indexes all nodes, and allows all of them to be searched by anyone. There are reasons to disallow nodes of certain bundles to be searched, such as when those nodes do not have canonical pages.
Proposed resolution
Add an option to \Drupal\node\Plugin\Search\NodeSearch
to limit the searchable node bundles, and apply this as a condition to search queries.
Remaining tasks
- Test coverage.
- Upgrade path.
User interface changes
A list of checkboxes appears in \Drupal\node\Plugin\Search\NodeSearch::buildConfigurationForm()
.
API changes
None.
Data model changes
The addition of one mapping item to search.plugin.node_search
, which requires an upgrade path.
Comment | File | Size | Author |
---|---|---|---|
#8 | interdiff.txt | 646 bytes | bfr |
#8 | drupal_2677370_8.patch | 14.46 KB | bfr |
#6 | drupal_2677370_6.patch | 14.46 KB | Xano |
#6 | interdiff.txt | 716 bytes | Xano |
Comments
Comment #2
XanoComment #4
XanoAdded test coverage. I realized the upgrade path is not needed, because config validation does not fail on missing data, and the search plugin comes with its own defaults.
Comment #6
XanoComment #7
bfr CreditAttribution: bfr at Druid commentedReviewed and seems to be working fine, good job and absolutely a needed change!
Just a small nitpick, you left a typo in a comment :P
// Turn the filters intp query conditions. This assumes that everything in
After that this is RTBC in my opinion.
Comment #8
bfr CreditAttribution: bfr at Druid commentedComment #9
bfr CreditAttribution: bfr at Druid commentedComment #10
jhodgdonUmmmmm.... Why was this not put into the Search module component? I know it's technically in node.module but traditionally, anything about Search has been part of search.module component.
Can the search module maintainers have a moment to review this?
Comment #11
jhodgdonAlso this is a duplicate of #111744: Add configuration to exclude node types from search indexing which has been open for YEARS.
Comment #12
jhodgdonThis type of change is out of scope for the stated issue. Please move to a separate issue.
Out of scope.
Out of scope.
Why use such a long complicated name for this config?
I don't think checking that the configuration == [] is a good way to check -- use the PHP empty() function instead?
It seems like we'd need to somehow merge the filters together to enforce this right. And what if someone manually put ?type='article' into the search URL, even though that wasn't allowed as a searchable node bundle? I think it would allow them to search for content that shouldn't be searchable. This needs testing and I think it's wrong.
This is a setter, not a getter.
Comment #13
jhodgdonComment #14
jhodgdonAnyway I would rather this got marked as a duplicate of #111744: Add configuration to exclude node types from search indexing, since it has a 9 year history and many followers. I'll let you move this patch over there first...
Comment #15
jhodgdonI also want to point out that if you really want to exclude node types from searches, the best way to do it is not to index them in the first place, rather than to index them and then use a filter on the search.
Comment #16
XanoNo, because the configuration is owned by the plugin instances, which merge in defaults. Schema validation does not validate missing data.
I needed to research the structure of these values in order to fix this issue. I included the change here because I believe it is in scope, as it helps reviewing the changes that this patch makes by preventing reviewers from having to look up this information themselves.
Because short names are not always descriptive. This item contains bundle names for a specific purpose. The key describes that purpose.
Why is it not a good way? An empty array means there are no restrictions. Using
empty()
only serves to hide any faulty array values. This is documented in::defaultConfiguration()
, and this condition reflects that.Well-spotted! I relied on the
#options
validation of thecheckboxes
element, but forgot this form can be submitted using GET as well, and in doing so the form validation can indeed be bypassed. You're right that this needs to be fixed.It seems we cannot. All node searches use the
node_search
plugin, but these filters are applied per plugin instance and as such per search page. We only know about the filters when instantiating a plugin based on its configuration as stored in the search page entity, which we do not have when marking nodes for indexing innode_reindex_node_search()
. The only way to add it there would be to load all search pages, find the ones that usenode_search
, and useNodeSearch::getRestrictedSearchableNodeBundles()
to find the node types that are excluded from searches, and exclude them from indexing as well.Comment #17
XanoMoving to #111744-102: Add configuration to exclude node types from search indexing.
Comment #18
XanoComment #19
XanoI moved the documentation changes to #2712367: Extend EntityTypeBundleInfoInterface's docblocks and make them more explicit and its related issues.