-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[META] Improve core search. #1332
Comments
Issue #1752 by alexfinnarn: Automatically include a local settings fi… looks good.
There was discussion about some ideas for improving core search in the Feb 7, 2019 Outreach meeting: https://youtu.be/LGOHoHvJTbk?t=139
|
Maybe also of interest: there's an initial port of the Search API module in contrib: https://github.com/backdrop-contrib/search_api |
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"). |
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.
|
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;-) |
Picking any of the issues listed in the issue summary of this one would be great @mazzech. |
@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. |
@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. |
@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. |
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. |
Another suggestion for the search settings page: |
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 :) |
Thanks @jenlampton, I will if I have another idea. |
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 |
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 |
Is the |
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. |
Sounds good, @mazzech! One thing I particularly like is the option to use the filter Operator |
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;-) So the goal is that "Search by Views Only" also findst those two pages with this string here: |
@mazzech It works for me using a Relationship to get the taxonomy name, see #1332 (comment) above. |
Wow @olafgrabienski this really rocks... cool:-) Even after 10 years I learn new things about Views, although I use relations a lot. |
Even works with parts of taxonomy terms:-) |
@jenlampton thank you for tracking the issue:-) |
I wonder if |
Todo:
Completed issues:
Users in the search index are not properly re-indexed. #1329 Users in the search index are not properly re-indexed.The text was updated successfully, but these errors were encountered: