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.

CommentFileSizeAuthor
#4 search_api.bundle_filter.patch4.95 KBdrunken monkey
#2 search_api_content_type_filter.tar_.gz1.12 KBAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drunken monkey’s picture

In 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.

Anonymous’s picture

I'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

drunken monkey’s picture

Version: 7.x-1.0-beta5 » 7.x-1.x-dev
Status: Active » Needs review

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?

I 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).

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 ...

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.

You thinks it's better to create a path or a seperate contrib?

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.

drunken monkey’s picture

Anonymous’s picture

Tested and everything looks to work fine :-)

drunken monkey’s picture

Title: Search index based on content type / possibility to include / exclude certain entities on their content type » Filter indexed items based on bundle
Status: Needs review » Fixed

Excellent.
Committed it, thanks again for your work!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.