Updated: Comment #1

Problem/Motivation

The Core Search module uses its own queries and results templates. We are trying to have most of Core instead use Views rather than custom queries and results displays. So the objective here is to display search results as Views, and integrate into Views as much as possible.

Proposed resolution

The following should be provided to Views, on #1853536: Reintroduce Views integration for search.module (not supporting backlinks view) -- [Views Integration piece]
- Filter for nodes that behaves exactly like search keywords do now (i.e., ability to perform a search using Views instead of the current search form).
- Hopefully a generic filter that you could use for other search plugins that use the search index.
- Output formatter that shows an excerpt based on the submitted keywords (i.e., ability to output excerpts with search keywords highlighted).

Once that is done, hopefully we can replace custom queries that are currently done in the Search module to produce search results with default Views [Replace with Views piece]. This would buy us:
- Ability for people to add additional filters (author, taxonomy, fields, etc.) on Node searches.
- Ability for people to change the number of search results.
- Ability for people to change the formatting of output.

Note that we still want to have the same search plugin system that we have now.

Remaining tasks

1. Views Integration piece from Proposed Resolution.
2. Replace with Views piece from Proposed Resolution.

User interface changes

Hopefully minimal.

API changes

  • Probably the way the "advanced search" facets were done in #2003482: Convert hook_search_info to plugin system (which was already a change from Drupal 7) would change to being Views filters.
  • We might also want to change the search plugin API a bit (also introduced on that same issue, and new for D8 anyway), if that makes Views integration easier.

Part of this meta issue:
#1823450: [Meta] Convert core listings to Views

Follow-up to #2003482: Convert hook_search_info to plugin system

Related to #1853536: Reintroduce Views integration for search.module (not supporting backlinks view), which is part of the meta issue #1853522: [META] (Re)introduce Views data integration for core modules

Would probably resolve:
#111744: Add configuration to exclude node types from search indexing
#144043: Allow searching by fields and taxonomy
#233476: Add search by node creation date and the author
#237748: Decouple core search module implementations from node and user module (and turn search/node and search/user to views).
#256792: Figure out how to allow advanced search operands (alongside type:, category:)
#278958: Advanced search form has usability issues
#702940: Make the number of results per page configurable
#987210: Language-specific searches should include language neutral content
and possibly others.

Comments

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

I found
#1853536: Reintroduce Views integration for search.module (not supporting backlinks view)
which had a start of this and is also about backlinks, which are not needed by Search itself. I'd like to make this issue about replacing the Search guts with Views and leave backlinks to the other issue?

jibran’s picture

jibran
he/him
Primary language Urdu
Location Sydney, Australia
CreditAttribution: jibran commented
Issue tags: +VDC

Tagging

jibran’s picture

jibran
he/him
Primary language Urdu
Location Sydney, Australia
CreditAttribution: jibran commented
Issue summary: View changes

add more related issues

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

So, I would first consider this potentially blocked on: #1941672: Remove Drupal\views\Plugin\query\QueryInterface

Basically, I think we'd need to make each search plugin implement that interface (once it properly exists) how to feed the search plugin to views as the query object (roughly - haven't dug in).

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

...I guess you meant #1941672: Remove Drupal\views\Plugin\query\QueryInterface

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

Yes, fixed my comment

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Basically, I think we'd need to make each search plugin implement that interface (once it properly exists) how to feed the search plugin to views as the query object (roughly - haven't dug in).

I don't think that adding the views interface to search is the proper approach, because

  • If you don't use the database sql query backend, you pretty much loose a lot of power of views: Fields for example might not be supported, relationships etc. also not

Isn't there a way to just integrate the search tables in views?

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

No, the only reason to use views here is basically as a presentation engine. Any given search implementation should be able to be replaced with one that return the same data using a different back-end.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

Integrating the search tables in Views is a separate issue #1853536: Reintroduce Views integration for search.module (not supporting backlinks view) and although I put it into this Proposed Resolution, I think we should take care of it there.

Once that is done, I think we should still consider this issue but we may decide it is not a good idea.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

So, I discussed some with dawehner. I think this may not be a good idea in general, or would be more work than the payoff is worth if we make each search plugin a generic query plugin that doesn't expose SQL info to Views.

However, it seems there may be value to integrating the code node one so that you can do keyword searching in Views plus get the benefit of full control of the node results display, joining other tables. etc.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Issue summary: View changes

...added a couple more issues in the "Would probably resolve" list.

rcross’s picture

rcross CreditAttribution: rcross commented

is anyone working on this?

@pwolanin - do you still think this is a bad idea? can you suggest any alternative approaches?

I've been hit in the past by several of the issues that this would resolve, so I am considering having a go at implementing it.

rcross’s picture

rcross CreditAttribution: rcross commented

looking over #1853536: Reintroduce Views integration for search.module (not supporting backlinks view), there seems to be the semblance of a working patch. Does it just need to be cleaned up and isolated from the backlinks parts?

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Issue summary: View changes
Status: Active » Postponed
Related issues: +#1853536: Reintroduce Views integration for search.module (not supporting backlinks view)

On that other issue, what's being done is to make sure that search data is *available* in Views. It is a prerequisite to this issue, which would be to make the search results page *into* a view. I guess we should probably postpone this one until that other one is done.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Postponed » Closed (won't fix)

I'm closing this as "won't fix" per discussion w/ jhogdon. Search module needs to be a generic api, but Views is not a *generic* presentation layer.

So, the linked issue can be fixed, but I don't think this is appropriate for core.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

I totally don't know how the Search API works, but I was under the impression that what this issue here (combined with #1853536: Reintroduce Views integration for search.module (not supporting backlinks view)) was trying to achieve is to make Views queries rely on Search API. So, the low-level searching would still be done by Search API and at the same time we'd allow users to alter both a) filter widgets of search forms as well as b) the way results are presented.

If I'm mostly right about what I say above, then this still seems like a perfectly valid task and a feature worthy of core (especially now that Views is part of it). Do I got all this wrong?

rcross’s picture

rcross CreditAttribution: rcross commented

I would agree with Klonos. With views in core, I don't see the technical argument against this. Doing this would also address many smaller issues like #702940: Make the number of results per page configurable

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

Well, we could possibly reopen the issue... But #14 has it backwards.

#1853536 basically makes it possible for people to use Views to build a search page configured however they want (with additional filters, different output formatting, etc.). It brings the Core Search index of Node content to Views. And it also makes another table that lets you filter based on "node A has a link to node B", at least if you ignore the fact that (as in previous versions of Drupal) the calculation of "node A links to B" is pretty stupid and may not be entirely accurate (to say the least).

What this issue is about is that if you go to one of the configured search pages like "search/node" or anything else you have set up, Views would be used to generate that page instead of the current Search module's code. The main reason I don't think we want to do that is that the core Search module allows contrib modules to define "search plugins" (core comes with a "user" and a "node" plugin). Each search plugin can define whatever they want to be the behavior for executing the search, given the keywords the user has entered. This is not really compatible with the idea of Views data, which is specifically table joins.

Now that we have the Search module with configurable pages based on each plugin, adding the ability to configure the number of search results is actually pretty trivially easy, whereas replicating what the search module is already doing for generating search results in Views would be quite difficult, and I just don't think this is a great idea. I'm not saying it couldn't be done, I'm just saying I think we have a pretty nice admin UI for setting up and configuring search plugins now, and can make more things configurable now pretty easily, and I would prefer to spend our Search module contribution time making what we have better rather than deciding to completely abandon the existing Search plugin system in favor of Views.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented

Just linking #1853536: Reintroduce Views integration for search.module (not supporting backlinks view) as per #16.