Hi Allon - I like the idea of splitting out the fields logic but there is a logical issue with your approach I think.

When you search 'all' and search for two words e.g. "apple" and "pear" - an article with "apple' in the title and 'pear' in a custom field should be returned. In your approach this will not happen.

I just ran a test search and can confirm that the correct results are not returned when searching for 'all words'

Yes, discovered that as well about an hour ago. An idea how to fix it?

when doing all you need to search for each word separately and return these muliple lists and incorporate them into the plugin search in the way that I did. It took me a little while to figure out the logic.

So you could look at how I do it in my PR and replicate the underlying logic but calling your field model code for the lists of matching item_ids

Didn't get you. Can you explain it a bit more?

In pseudo code we need (for all words matching):

(a.title like word1 OR a.introtext like word1 ... OR a.id IN (fields matching word1))
AND
(a.title like word2 OR a.introtext like word2 ... OR a.id IN (fields matching word2))
etc.

I guess it may be possible to combine these into a single query in your model and extract the separate groups of ids from the result set in some way but its not trivial and the extra PHP processing may cancel out the DB gains.

Closing as we can't properly, in a simple efficient way, handle the all combination.