search

flarum / issue-archive

0 stars 0 forks source link

Improve Global Search #97

Open askvortsov1 opened 3 years ago

askvortsov1 commented 3 years ago

Feature Request

In beta 16, we split the search and filter system. Extensions that filtered discussions by modifying q started doing the same by sending filter requests. However, this meant that when tag pages were visited while a search query was active, the query was not restricted to the page (https://discuss.flarum.org/d/26996-tags-search). That behavior should be restored in https://github.com/flarum/tags/pull/129, but it is symptomatic of some deeper issues in the global search system:

Firstly, we assume that the only resource that will have full-page search results is discussions. This causes issues with other systems: User Directory, which recently added user searching, had to do so via messy hacks.

I think that given our preference for simplicity, a page should only need to support one resource for searches. However, that resource should somehow be indicated by pages (maybe instead of providesInitialSource, have a static searchedResource field that has the ID of the JSON:API resource?).

Furthermore, Search Sources should be made more flexible. For starters, full page searches should be reified instead of just included as a link. Perhaps there could be a method (that could be overriden), which returns a list of route names where the source's resource can be searched? If the current route name is one of those, searching wouldn't change the page, just use a new q parameter. A default search route name could also be provided (index for discussions), in case the current page doesn't support search.

We'd also need to clear the search bar when switching from page to page, if the pages search different resourcees. This could be done

Instead of the hack done in tags, I'd like to see some way for extensions to register callbacks per route-resource-pairing that would return a "prefix"? So for example, if on a tag page and searching discussions, the tag:IDS prefix should be used?

Also, perhaps it might make sense to move search sources to SearchState?

Another question is whether options for search should be done per-page component or per-route? Page component is elegant because we reuse IndexPage for tags / following / etc. On the other hand, some behavior is granular on the level of routes (tag pages need different prefixes than following pages, and regular index pages don't need prefixes at all).

And this brings me to the Search component itself. Search is a weird component because it has a lot of potential to be useful, but is also restricted by its current design, which is too tailored to the current navbar position IMO. I'm not sure if there is a way to make it more generic without losing its power (if we could use it to power the Tags discussion tag modal, for instance), but that would be very useful for extension developers.

zerosonesfun commented 3 years ago

2.0 milestone? I came here to submit this issue hoping it was an easy quick fix. I see it is not. I think you're talking about this same issue, right?

I have a BBCode which searches the forum. The URL is hardcoded. If you set the discussion page as the homepage and use /all?q= it doesn't work. But if you use \?q= it doesn't work if the homepage is tags.