...

• LMSSearchResultsProcessor: since it has the user, it restricts access to blocks the user can see, and provides proper links. Not currently in use, so this may not work. For course staff users, it short circuits access checks which should help performance. For other users, it is based on a very standard get_course_blocks call, which could well be the only way to reliably guarantee that the restrictions on search match the restrictions on content in general. No matter how many matches are returned from a course only one such call will be made, but no matter how few matches are returned the call will always get all available blocks, so there might be room for optimization in the low match case.

The Search Initializer works at a different level. It is not attached to the API functions but is attached to the do_search course search view. It “sets up the environment” which doesn’t help us understand it much.

...

Doing their own searching means that these indexes can’t use the extension points, but it also means they don’t have to because the filters and results are customized to their particular use case.

One twist on Two problems wth calling this format a best practice: it’s

1. This search is not enabled by default or on edx.org, so unless it has other users it could be completely broken and we wouldn’t know.

2. The distributed nature of xblock content makes a unified schema extremely difficult, so this might not be applicable for course content search.

So Many Settings

There are minor settings for specific search tweaks I’m going to skip to keep these tables compact.

...

Special note for SEARCH_ENGINE

...

This setting is in lms and cms production.py, but it is only actually set if a selection of the other search settings are True. THAT SELECTION IS DIFFERENT FOR LMS AND CMS.

...