Processors apply to an index, but there are instances where it may be helpful for a processor to only be active in certain situations.
For example, recent profiling showed that we had a performance issue with the Highlight processor. This has been reported by another user in #3519704: Highlighter processor performance issue when fields are missing from search backend. But in our case we do not need it active at all for the specific view it was causing an issue for.
In our case, we have 1 index and multiple views. 1 view for a global search (which uses the highlight processors result) and other views which use the index to search a subset of the content. These do not use the results of the highlight processor. In our case, it is adding about 200ms to the page.
- Screenshot of php-spx output
I think the concept of turning a processor from global => opting out could be potentially be very confusing. I'm not sure if a similar use case exists for other processors.
In the Highlight processors case, I wonder if the simplest solution is to have a tag such as search_api_skip_processor_highlight that we could apply to the view. Then in the plugin's postprocessSearchResults method the processor could exit early if the query has this tag?
That would make it a bit of a hidden feature, but I don't think its something that all users are going to be particularly concerned with.
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot 2025-06-25 at 11-19-53 image.png (PNG Image 1931 × 312 pixels).png | 110.93 KB | ericgsmith |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
ericgsmith commentedIf this idea is something that could be accepted I can work on a patch - otherwise we will likely implement this by extending the processor to add the query tag check in a custom module - but we prefer to avoid custom code and upstream the solution if we can.As this is small change, adding an MR to show what I mean
Comment #3
ericgsmith commentedComment #5
ericgsmith commentedEasier to show what I mean with an MR - setting to needs review.
Comment #6
ericgsmith commentedComment #8
drunken monkeyThanks a lot for posting this suggestion, and sorry it took me so long to get back to you.
Your use case definitely makes sense. And while my first instinct was to come up with some architecture for skipping or even adding specific processors in a generic way (#1720348: Add the concept of query extenders would be something similar, but I think there was also some issue specifically for overriding the used processors on a per-query basis), you are probably right that just skipping the “Highlight” processor is the primary use case and before adding yet another complicated and rarely-used component to the framework, just doing this with a query tag seems like a great and simple option.
A query option would probably be a bit cleaner, but then you couldn’t just set it using the existing Views UI and we’d either have to add UI for it after all or people would need to implement an alter hook just for this. I think I can live with this just being a magic tag for now, we can see whether there is any interest in changing this or we notice any disadvantages.
I just added a small paragraph about this to the README.md file so people have a better chance of finding out about it. Please review and tell me what you think, otherwise I think this is RTBC.
And thanks again, especially also for already including test coverage!
Comment #9
ericgsmith commentedThanks Thomas - the update to the README looks good to me - thank you for the review!
Comment #10
drunken monkeyGreat to hear, thanks for reporting back!
Merged.
Thanks again!