Global search in my experience has seen very poor uptake and I think the root cause of this is at two levels, maybe this should be two trackers but I think they overlap a lot:

1) Global search isn't on by default or guaranteed to be on, so there is very low pressure on plugin authors to add support

2) Global search isn't a generic api that can be used for adding search to other things, and even if it was it would be hamstrung by point 1, which means plugin authors end up implementing their own search manually which then makes it pointless to implement global search.

What I have in mind is Global search is conceptually treated the same way as say cache stores:

a) there is always a default zero-config engine ready to go and on

b) plugins or parts of core can declare a new concept, lets call it a 'search domain'. There would be one default search domain which is 'global search'

c) analogous to cache config there is admin level config to map 'search domain's to various engines.

d) in the same way that there are DB specific Lock API factories for each major DB core could ship with a broad support generic engine (eg search_simpledb) and then a couple higher performance ones for the most common DBs (eg search_postgresfulltext)

Even if what we think of 'global search' is not turned on for end users, the core set of api's would always be available, and so plugins can have a single set of way to search for content. The default 'global search' 'search domain' could default off as it is now.

Some candidates for moving to this new api would be:

i) Admin settings - this search can sometimes be brutally slow

The two places which currently uses searchlib could be refactored to use this (some cross over with MDL-71934). These include:

ii) Forum search

iii) Config log search

iv) Course search

v) wiki / data / blog / badge numerous other places that search

vi) Very likely some interaction with searching in report builder

and finally this came up today in a meeting around Quiz 4.0 (MDL-70329):

vii) Search within the question bank, which can be ginormous, eg one of our clients has ~40 million questions and it would be way better if we could push that search load onto an engine like elastic and out of the main DB.