The search box on the Studio homepage only finds courses whose names contain the search keyword. If there is any mismatch, even if it’s very small, the course will not be returned.
This is because the search API uses SQL queries to search the MySQL database, which is not flexible (or suitable) enough for text-based searches.
This problem arises in large instances, where an author (or staff) might have many courses and they want a better search/filtering mechanism.
Suggested solution:
We already have a search engine (meilisearch/elasticsearch) and the course data is already indexed; we should leverage this search engine for this type of task.
We just need to index an additional block block_type = ‘course’ and optionally add a field for course_run.
As far as I can tell in my instance at least, the Search box on v20.0.5 still uses the legacy search methods, there was a beta search introduced in Redwood that uses the Meilisearch features, which you can access using the magnifying glass icon at the upper right of the screen:
in the event you get no results, try reindexing your studio: tutor local run cms ./manage.py cms reindex_studio --experimental
Maybe give that a try and see if it yields more reliable results.
As far as I can see it’s still not particularly forgiving with typos, but it looks like meilisearch can support typo tolerance, but I didn’t notice any of this in the codebase, so might not be implemented, maybe a useful feature for devs to test
Thank you for the response, but that’s not the search box I was talking about; my post was about the search box right below the Courses tab (see post image). Although the search box you mentioned (the search box on the navigation bar) is the reason I suggested we use the same index to improve the search experience.
We could replace the course search features on the Studio home page with a search based on Meilisearch (and the libraries search as well). That would indeed provide better typo tolerance, fuzzy searches, etc. But there is a downside which is that Meilisearch powered features require Meilisearch to be running and its index up to date. From the initial adoption of elasticsearch until the present day usage of Meilisearch, we have yet to get to the point where all installations of Open edX have a stable search engine with an up-to-date index. We still need a proper solution for handling index migrations, replacing edx-search with a new abstraction layer that supports Meilisearch and Typesense, and providing better visibility/tooling/recovery for indexing.
So, for now, I’m not in favor of changing the Studio home to be search-index powered, because viewing the list of courses is a core feature that all course authors rely on daily, and we can’t accept it being unstable or incomplete or unavailable on some instances. But once we improve the way the platform integrates with search engines, yes, that would be a great improvement.
I think for this specific problem, we only need metadata about the courses, such as display_name, org, run, etc., and not the content of the courses, i.e., the content of the blocks. This way, the data needed for this problem can be indexed very quickly and more up-to-date.
Administrators can choose to index other content (the content of the blocks) if they want, because this process takes a very long time to complete, and even when the server is running, indexing the course block content consumes a lot of resources and puts other important tasks in the queue, all for the sake of searching the entire course, which is really not important.
