This feature would implement avatars into search suggestions, if the person is searching up another user in the search component of a wiki basically. A basic concept of it is displayed at http://s.codepen.io/SamanthaNguyen1116/debug/amOAyx
Description
Description
Event Timeline
Comment Actions
Here's a different, quick mockup I did yesterday using medium-size (m) avatars:
The HTML is literally <img src="path_to_the_users_m_avatar.ext" alt="" /> inside div.suggestions-result before span.highlight. There's no additional CSS styling or anything (hey, I did say it was a quick mockup!) which is why the avatars are somewhat (too) close to the user/page names and whatnot, but I'm sure we can solve that once we've dealt with the hardest part here.
The core code that takes care of search suggestions is in resources/src/mediawiki/mediawiki.searchSuggest.js and it seems that its "back-end" is resources/src/jquery/jquery.suggestions.js.
One thing to consider is that the avatar file name format uses $wgAvatarKey (which is set to $wgDBname by default), which is not exposed to JavaScript currently. Should it be? I'm thinking the answer is "yes", because while its default value indeed is $wgDBname (which is exposed to JS), it can be customized and it has to be customized for wiki farms and the like which want global avatars.
I'm not sure what would be the best way to add that <img> into the generated results HTML (for search results beginning with "User:" or its localized equivalent), however; cc'ing @Krinkle and @matmarex as the local JS gurus for further input.
Comment Actions
@ashley I've got an idea for how to make this work, but it does require responsibility to be in the skin, which means it can't be displayed while using Vector.
I didn't foresee the use case of avatars, but a few years ago it did come up that search suggestions should not be a hardcoded, uncustomizable, feature that is loaded by default and can't be disabled by skins (short of soft-disabling by giving your search field a different ID, so the script is a no-op).
I addressed that use case by starting a long-term initiative to make things more extendable and to move control of the front-end output (mostly) to the Skin class, instead of hardcoded in OutputPage. This project has mostly been finished now, and the way you'd use it is as follows:
- Create your own module (e.g. skin.yourskin.search) that re-uses the underlying jquery.suggestions from core, but implements a different render callback.
- From YourSkin::getDefaultModules, call the parent method and return $modules with one change: remove the 'mediawiki.searchSuggest' entry in $modules['search'], and add skin.yourskin.search instead.