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.
I would also like to create an include / exclude matrix for a search index based on the content type of the entity
for example only node - page or comments - blog
Would it be better if I try to create a patch for the search_api or try to create contrib module for this feature?
Greetz
Tim.
Comment | File | Size | Author |
---|---|---|---|
#4 | search_api.bundle_filter.patch | 4.95 KB | drunken monkey |
#2 | search_api_content_type_filter.tar_.gz | 1.12 KB | Anonymous (not verified) |
Comments
Comment #1
drunken monkeyIn any case, this can be done rather simply by creating a data alteration. You'd just have to provide a form for selecting the content types (for entities where there are any) and then unset all entries in
$items
that should be excluded during indexing.If you really make it generic (i.e., make it work for all entity types with different bundles — which shouldn't be too hard to do) I'd be glad to add it to the base module. Otherwise, a contrib module would probably be best.
By the way, there is already a much more ambitious issue (#939430: Integrate Rules conditions to filter indexed entities) that would incorporate this use case, if you are feeling brave. ;) However, it's probably best to leave that be for the while, as it's sure to be a lot harder to implement than this one.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedI've created a small contrib, that will filter nodes based on content type (include or exclude).
I've only made it for nodes, because for other entities you would have to check if there is a node attached and then load the node to check the type, have ommitted this for now for performance reasons, what do you think?
There is on the other hand still a small bug in the count for the indexed items, it doesn't take into consideration that some nodes might be filtered out after alterItems, So It might send 3 items to solr and ommit 1 item, but it still would say, committed 4 items ...
You thinks it's better to create a path or a seperate contrib?
Greetz
Tim
Comment #3
drunken monkeyI didn't mean you should be able to filter on the node content type of an attached node, but generally on the entity's bundle (content type for nodes, node content type for comments, vocabulary for taxonomy terms, et cetera). You would just have to check the entity info if there are any bundles, and which, and from that create the select field (and then check the bundle key during indexing).
This is by design. In my opinion, it's irrelevant for the user whether all items were actually indexed, as long as they don't need to be indexed any more, meaning that they are now correctly incorporated in search results.
There is, however, as I see now, another bug because items that are rejected by a data alteration might already be indexed on the server but won't be deleted then.
As said, as long as it only works for certain entities (even though nodes are of course the largest use case) I don't think it really fits into this module.
However, as I knew what to do anyways, I figured I'd just rewrite the thing myself — attached patch does that, and also fixes the above-mentioned bug. If you agree, I'll just commit that version to the project and you don't need to create a new project just for that.
Comment #4
drunken monkeyComment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedTested and everything looks to work fine :-)
Comment #6
drunken monkeyExcellent.
Committed it, thanks again for your work!