-
Notifications
You must be signed in to change notification settings - Fork 217
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
Add parsing raw query for modifiers #133
Comments
Cool idea! |
Great idea, I have some thoughts on how this could be implemented but it needs work in two places (so maybe we could move it to the WordPress/openverse repo). API: Ref:
Frontend: The frontend might also need some work to parse queries containing advanced filters and populate the UI based on those. For example, when searching for |
@dhruvkb That's such a good point, this is basically just moving the query params into the raw query, the format is almost exactly the same if you replace |
* Simplify catalog folder structure Signed-off-by: Olga Bulat <[email protected]> * Move pyspark- requirements to archive Signed-off-by: Olga Bulat <[email protected]> * Simplify `common` module imports Signed-off-by: Olga Bulat <[email protected]> * Fix import paths Signed-off-by: Olga Bulat <[email protected]> * Remove `.github/workflows-disabled` folder * Move jamendo and stocksnap scripts to the correct folders Co-authored-by: Krystle Salazar <[email protected]>
Strongly related to #3328 |
Problem
Currently from the frontend if you want to search for
galah
images that arecc0
you'd need to execute a search forgalah
first, then use the UI to add thecc0
filter.For power-users this adds an unnecessary extra step.
Description
We could add a feature like most search engines have and allow the query itself to supply extra parameters of the search. For example, we could add a (not well-named)
license
option that could work like this:This would automatically select the cc0 and pdm filters. Similarly:
And so on, would also work.
I think it'd be best to implement this on the API side rather than directly in the frontend so that this feature would be automatically available to any frontend that hooks up to the API without having to reimplement the parsing.
Additional context
This feature would require an implementation plan if we decide to do it.
Implementation
The text was updated successfully, but these errors were encountered: