I'm looking for a way to not list my processors (fuzzysearch) on indexes where they won't work.

Could processors specify a reqiured service class?

Or , if $index were passed to the hook I could check the service class being used.

I'm happy to provide a patch with your direction.

#2 search_api.supportsIndex.patch5.25 KBdrunken monkey
Members fund testing for the Drupal project. Drupal Association Learn more


drunken monkey’s picture

Title: Pass $index to hook_search_api_processor_info() or let processors specify required service class? » Let processors and data alterations decide on which indexes they can run

If we would solve this, it would probably be through a new SearchApiProcessorInterface::supportsIndex(SearchApiIndex $index) method which would let processors decide dynamically which indexes they want to support, depending on any criteria they want. (And probably we should then add the same method for data alterations.)

However, I'm not sure this is a good idea for service classes, as those can be changed later. You'd still have to check for the current service class when the processor is called – so maybe you should just do that and include a note to this effect in the processor description. A processor appearing or disappearing when the server is switched might confuse users.

Anyways, the feature request itself is a good idea – most prominently there will probably be several processors and/or data alterations specific to a certain entity type. Giving those an easy way to "hide" themselves for other indexes would certainly be handy.
I'll come up with a patch, shouldn't be more than a couple of lines of code.

Also, as a side note, instead of depending on a specific service class you should depend on a feature, using the supportsFeature() method.

drunken monkey’s picture

Status: Active » Needs review
5.25 KB

See the attached patch.

Open questions:
- Is supportsIndex() the right/best name?
- Are the doc comments clear and fitting?

It at least works insofar as the bundle filter isn't displayed for, e.g., user indexes anymore.

awolfey’s picture

This makes sense to me. I can imagine, however, that there may eventually be a set of processors that all support an index, but are incompatible with each other. I think a processor could test if an incompatible proccesor were enabled and then "hide" or disable itself or display a warning message. So "Immutable" may be a bit strong.

I haven't had a chance to test this yet. I'll try this week.

drunken monkey’s picture

In the end, "immutable" is just my suggestion. I can't stop people from checking for other things, but then they should do it right (and also check e.g. on hook_search_api_index_update() whether the respective parameter has changed) and I don't take responsibility otherwise. ;)

awolfey’s picture

The patch works fine for me. Thanks.

drunken monkey’s picture

Status: Needs review » Fixed

Great, just committed this.

Status: Fixed » Closed (fixed)

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