I'm guessing ResourceLoader has fixed this.

(In reply to comment #1)

I'm guessing ResourceLoader has fixed this.

It hasn't, actually. It won't really be convenient to do this until Extension:Vector is moved into core.

Removing as a ResourceLoader 1.0 blocker.

Possible solution:

• Introduce a new method in OutputPage, something like "unloadModules" (which is like "addModules", but the opposite (removes from this->mModules)).
• in the Vector extension, if SimpleSearch is enabled, unload 'mediawiki.legacy.mwsuggest'

What we may want here is a system for aliases or virtual modules.

It's fairly common in Linux app packaging systems for instance to have a notion that multiple packages can provide some particular service. sendmail, postfix, exim etc will all claim to offer 'mail-transport-agent' for instance, so any other package that needs _some_ mail agent but doesn't care which can simply declare its dependency on that, and whichever is available (or chosen/prioritized) gets actually used.

If we consider SimpleSearch's module and mwsuggest to both provide, say, 'mediawiki.search-suggest', but SimpleSearch's takes priority, then poof! We only need to ask for one, and we get the awesomest one.

One simple way to implement this might be to just create a dependency-only module and override it:

$wgResourceModules['mediawiki.search-suggest'] = array(

'dependencies' => array( 'mediawiki.legacy.mwsuggest' ),

);

... then when setting up the extension ...

$wgResourceModules['mediawiki.search-suggest'] = array(

'dependencies' => array( 'ext.vector.simplesearch' ),

);

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

The following are the steps to load ext.vector.simpleSearch:

• Install Vector extension
• Enable vector-simplesearch (either as default user option, or by setting 'global' to true in $wgVectorFeatures['simplesearch'])
• The requirements in VectorHooks::features for 'simplesearch' must match the current scenario: 'requirements' => array( 'vector-simplesearch' => true, 'disablesuggest' => false ),

... mediawiki.page.mwsuggest:

• $wgEnableMWSuggest = true;
• use option 'disablesuggest' undefined or false

Another possible solution, that doesn't involve creating a new infrastructure for aliases in resourcemodules:

Perhaps add a hook in OutputPage->addDefaultModules

Current code

		// Add various resources if required
		if ( $wgUseAjax ) {
			...

			if ( $wgEnableMWSuggest && !$this->getUser()->getOption( 'disablesuggest', false ) ) {
				$this->addModules( 'mediawiki.legacy.mwsuggest' );
			}
		}

Proposed code

		// Add various resources if required
		if ( $wgUseAjax ) {
			...

			if ( !$this->getUser()->getOption( 'disablesuggest', false ) ) {
				$searchSuggestModulesNames = array();
				if ( $wgEnableMWSuggest ) {
					$searchSuggestModulesNames[] = 'mediawiki.legacy.mwsuggest';
				}
				wfRunHooks( 'getSearchSuggestModuleNames', array( &searchSuggestModulesNames, &$this ) );
				$this->addModules( $searchSuggestModulesNames );
		}

mediawiki.legacy.mwsuggest and ext.vector.simpleSearch exist no more. There is now a modern skin-agnostic implementation in MediaWiki core.