Add option to expose searched fields in Views fulltext filter

Thanks a lot for posting this! Please apologize my delay in responding.
Before going into the details of the patch, I have a number of questions/remarks:

1. Wouldn‘t it be possible to just make this an (optional) part of the SearchApiFulltext filter’s exposed form? After all, there is already a setting there to set the fields to search.
2. Is there a reason to make this a negative filter, and not just let the user select the fields they do want to search on? Seems unnecessarily complicated.
3. The current code doesn’t look like it would work when no fulltext fields were explicitly set. Please be aware that getFulltextFields() can also return NULL (meaning “all available fields”).
4. If they’d remain separate, it seems this filter would be dependent on running after the SearchApiFulltext does, or risk being just overridden by its settings. Is there any way to defend against that, or would this be the user’s responsibility?

Initially, in Search API Attachments, the feature was to have a checkbox to exclude search in attachments. I guess an exposed checkbox is more user friendly than an exposed list of fields to search among. I am open to suggestion :)

Yes, agreed, the UX for this is probably not optimal. Most sites would probably need to apply custom stlying/scripts to make this behave the way they want it to. Still, I think it’s an improvement to have this option available right in the filter, to expose the searched fields. That would at least eliminate one part of custom code this use case currently needs.

I was not aware of that. Is there a way to have exposed filters triggered in an order different from their display order?

No, I don’t think so. So yes, making this part of the SearchApiFulltext filter is probably the best way to go.

Thanks for your continued work on this! Attached are some small adaptions by me.

Yes, please do change the logic of the form field to make the selection positive.

Also, I saw these problems in the admin UI:

1. “Expose searched fields” is available even if the filter itself isn’t exposed.
2. Once you enable the option, the “Exclude from search” select box is also present when configuring the filter in the admin UI. It should only be present when the form is exposed.

Thanks a lot, looks pretty much flawless now! Also works well, in a quick manual test.
So, thanks, and sorry for the huge delay!

To be honest, I’m not too strict regarding automated tests for smaller Views features, I think I would commit this without an automated test, too. If you want to be extra-awesome, though, I’d of course also be glad about test coverage. If you do want to add some, I’d suggest adding a functional test in the following way:

In \Drupal\Tests\search_api\Functional\ViewsTest::testSearchView(), after the call to regressionTests(), add code to enable this feature for the search_api_test_view view and then test it in some way. (You can find the test content used in this test in \Drupal\Tests\search_api\Functional\ExampleContentTrait::insertExampleContent() – there, just pick a word where it makes a difference which fields are searched and then test that via $this->checkResults().

Wow, that was quick! Thanks!

Should we make an update hook to update existing views to have config updated with the default option value?

I think with the entry in \Drupal\search_api\Plugin\views\filter\SearchApiFulltext::defineOptions(), missing values should be handled fine, so no need for that. It also wouldn’t have been necessary for the exported test views – but probably no harm in that, either.

When testing on the search_api_test_view, I found that the new exposed "search fields" select list is not grouped with the fulltext exposed filter with the option enabled. And if there are multiple fulltext exposed filters it applies to all the fulltext exposed filters because the machine name of the exposed element is not changed automatically to match the filter id. I don't know if the case of multiple fulltext exposed filters is a common case. Personnally I almost only encountered a single fulltext exposed filters with facets. See attached screenshot.

Ah, OK, that’s of course unfortunate. While you are of course correct that multiple exposed fulltext filters are rather rare, they aren’t completely unheard-of. Probably, the right way to implement this is like an exposed operator, with the option to choose the used GET parameter (and a check that it is unique). Maybe we should just go through \Drupal\views\Plugin\views\filter\FilterPluginBase and copy everything related to exposed operators … (E.g., defaultExposeOptions() also looks useful. Plus, we might want to nest this option under 'expose', for the sake of consistency.)

Actually, let’s do that last one in any case – patch attached. All the others we can also just fix if someone complains, in case you are tired of working on this. I think I’d still just commit this now as-is – it’s still an improvement, even though not perfect.
On the other hand, if you have the nerve to still work on this, I’d of course be happy to hold off and help you polish this further.

In any case, thanks a lot again!

PS: Where the heck did those 114 fails come from for my patch, and why are they gone without any related changes?!? Maybe a Core bug?
Can probably ignore as long as they don’t appear again …

Thanks, happy new year to you, too! And sorry for the long delay in getting back to you.

Regarding the patch: Excellent work, thanks a lot once again! I just changed a bit of whitespace and removed the unnecessary isset() calls (!empty() already contains isset()), otherwise this looked flawless.
So: Committed.
Thanks a lot again!