[META] Improve core search.

[klonos]

Todo:

• Easier Facets
• Integration with views
• Smarter Defaults
• Add comprehensive settings on a field level
• [DX] Provide a way to alter search results #1143 [DX] Provide a way to alter search results
• [UX] Implement N-Gram/Porter-Stemmer/Fuzzy/Partial-Word search in core. #1320 [UX] Implement N-Gram/Porter-Stemmer/Fuzzy/Partial-Word search in core.
• Put all search results on a single page (with facets?) #1330 Put all search results on a single page (with facets?)
• Improve the way search (re)indexing works. #1337 Improve the way search (re)indexing works.
• [UX] Convert search to a view. #1338 [UX] Convert search to a view.
• [UX] Search settings: Convert the "Search items" section to a table. #3385 [UX] Search settings: Convert the "Search items" section to a table.
• [UX] Add content title match as search relevancy factor #3517 [UX] Add content title match as search relevancy factor.
• [DX] Remove hook_search_admin() in favor of a form_alter. #3518 [DX] Remove hook_search_admin() in favor of a form_alter.
• Search terms along with nodes #3850 Search terms along with nodes
• Fix exposed search filters in Views #4444 Fix exposed search filters in views

Completed issues:

• [UX] Add configuration to exclude node types from search indexing #4197 [UX] Provide a way to prevent some content from appearing in search index
• [UX] Display the default search setting option only if more than one search modules are active #4210 [UX] Display the default search setting option only if more than one search modules are active
• [UX] Replace "Node" with "Content" in Search Settings #1282 [UX] Replace "Node" with "Content" in Search Settings (implemented: Issue #1282: Search module question cleanup. backdrop#1116)
• [UX] Search: make it clear what the 're-index site' button does #1321 [UX] Search: make it clear what the 're-index site' button does
• Users in the search index are not properly re-indexed. #1329 Users in the search index are not properly re-indexed.
• [UX] Simplify and improve the "Search items" section under admin/config/search/settings #1336 [UX] Simplify and improve the "Search items" section under admin/config/search/settings

[cellear]

There was discussion about some ideas for improving core search in the Feb 7, 2019 Outreach meeting: https://youtu.be/LGOHoHvJTbk?t=139

• Easier Facets
• Integration with views
• Smarter Defaults

[olafgrabienski]

Maybe also of interest: there's an initial port of the Search API module in contrib: https://github.com/backdrop-contrib/search_api

[klonos]

This has been brought up during recent dev meetings:

The current D7 core search implementation (thus also inheritedly Backdrop core too) is so "basic", to the point where it simply does not work as expected at all. It seems that most sites eventually use https://www.drupal.org/project/search_api, https://www.drupal.org/project/search_api_solr, https://www.drupal.org/project/search_api_db, https://www.drupal.org/project/custom_search etc.

Point is that I believe that we'd be fixing more things than those that could potentially break if we replaced the core search with something more robust (assuming that the core search is not worth "fixing").

[jenlampton]

This was requested recently in the forum. So I'm adding a milestone candidate label. Not all these issues would make a milestone, but I do want to record this as being a priority for our users.

I would be pretty happy to have the current state of Search API in Backdrop CMS, including the comprehensive settings on a field level, e.g. Regular Expressions on a per-field base.

[mazzech]

Let me know where I can help I am still pretty happy with Search API, but honestly it's the only CMS search engine I know;-)

[klonos]

Let me know where I can help...

Picking any of the issues listed in the issue summary of this one would be great @mazzech.

[mazzech]

Sorry @klonos for my stupid question... what do you mean by picking? I think #1338 could be a good point to start (concerting search to a view), but what would be the next steps and where could I help (as a non-coder?). Thank you so much for helping (and all your other work for the project)

[olafgrabienski]

I am still pretty happy with Search API

@mazzech Are you already using Search API with Backdrop?

Re improving core search, I've the impression we could need a(nother) discussion about the best approach and/or prioritization of single issues and how they fit together.

[mazzech]

@olafgrabienski no, I did some initial testing, ran into WSOD and reported it: backdrop-contrib/search_api#1. However, it's some month ago, I did not tackle the issue since then.

[olafgrabienski]

@mazzech I see! Later in that issue, there is a comment by @herbdool about a possible reason of the errors. @docwilmot said he didn't know if he'd work on the issue but suggests to take it up again if people express demand for search modules. Looks like improvements to search are welcome but only a few people seem to need them urgently. I'd suggest however to state your interest once more in the Search API queue. And maybe ask for more feedback in Gitter or on the weekly Dev meeting about the question if we should focus on Search API or on core improvements.

[mazzech]

You are right, @olafgrabienski it was not urgent back then, it is not urgent right now, but we should raise the issue BEFORE it becomes urgent (and this will be in 2020). There's also a marketing aspect: I always add "better search" as an option into proposals, and it's a thing that customers are willing to pay for.

[alanmels]

Another suggestion for the search settings page:

#4184

[jenlampton]

Removing the milestone candidate minor tag from this issue since it is a meta. Any sub-issue can/should get that tag.

@alanmels Feel free to add issues you think are relevant to the top post -- use the edit link at the top right :)

[alanmels]

Thanks @jenlampton, I will if I have another idea.

[mazzech]

I just made some tests with search, based purely on a View. The GUI is amazingly fast (OK, the server is also new and pretty powerful...). https://backdrop.mazzemedia.ch/de/search (enter "Backdrop"...;-)

However, at the moment, it does not work with taxonomy fields. But the great Combine Fields Filter does allow to search several content fields through one input field

[jenlampton]

it does not work with taxonomy fields

Can you elaborate more on this @mazzech? What were you expecting to see in the search results, and what are you getting instead?

Are you hoping to see the taxonomy term pages in the search results (taxonomy/term/TID) or node pages (node/NID) for nodes that were tagged with that term? If the former, that's not supported in core at all. You'd need to add a module like term_search to get those pages indexed.

If the latter, the fields that are on the term would also need to be included in the node index, so they would need to be added to the Search index display mode. If that's what you've done and it's not working, we may need to create a separate issue to address a bug there.

[olafgrabienski]

the fields that are on the term would also need to be included in the node index, so they would need to be added to the Search index display mode

Is the Search index display mode also relevant when the view is a view of fields?

[olafgrabienski]

Is the Search index display mode also relevant when the view is a view of fields?

Just tested: No, it's not relevant.

But using the Combine fields filter to find content that was tagged with a taxonomy term, the taxonomy field -- e.g. Content: Tags -- doesn't do the job, I guess because technically it doesn't contain the name of the term. Therefore, the view needs a Relationship like Relationship: Content: Tags (field_tags) and the field Taxonomy term: Name which uses the relationship. That field should then be selected in the Combine fields filter.

[olafgrabienski]

I just made some tests with search, based purely on a View.

Sounds good, @mazzech! One thing I particularly like is the option to use the filter Operator Contains which returns even search results for partial-words.

[mazzech]

@olafgrabienski yes, really like it
https://backdrop.mazzemedia.ch/de/search
https://backdrop.mazzemedia.ch/de/search?combine=backdr
https://backdrop.mazzemedia.ch/de/search?combine=The+Eagle+has

[mazzech]

But both articles containing "Backdrop" have also an assinged category named "Apollo Mission" (I had to find a name which is unlikely to appear anywhere else on the site;-)
https://backdrop.mazzemedia.ch/de/site/apollo-mission

So the goal is that "Search by Views Only" also findst those two pages with this string here:
https://backdrop.mazzemedia.ch/de/search?combine=apollo

[olafgrabienski]

So the goal is that "Search by Views Only" also finds those two pages with this [category] string

@mazzech It works for me using a Relationship to get the taxonomy name, see #1332 (comment) above.

[mazzech]

Wow @olafgrabienski this really rocks... cool:-) Even after 10 years I learn new things about Views, although I use relations a lot.

https://backdrop.mazzemedia.ch/de/search?combine=apollo

[mazzech]

Even works with parts of taxonomy terms:-)
https://backdrop.mazzemedia.ch/de/search?combine=shut

[mazzech]

@jenlampton thank you for tracking the issue:-)
If the latter, the fields that are on the term would also need to be included in the node index, so they would need to be added to the Search index display mode. If that's what you've done and it's not working, we may need to create a separate issue to address a bug there.
What do you mean by "node index"? It's not based on any search module, just a view with contextual filter

[herbdool]

I wonder if term_search, which @jenlampton mentioned, would be a good candidate for core. https://git.drupalcode.org/project/term_search.