ResourceLoader does not check dependencies for existance
Closed, DeclinedPublic


Author: questpc

I developed my extension in 1.18wmf1 then in 1.20 master. One of ResourceLoader modules, defined by extension has the following dependency:

			'dependencies' => 'mediawiki.jqueryMsg',

The 'mediawiki.jqueryMsg' module and it's script is present in 1.18wmf1, 1.19, 1.20 master, but I was really surprised that in 1.18.2 it does not exists so the page scripts where my extension module is requested were broken with the following Chrome console errors:

Uncaught Error: Unknown dependency: mediawiki.jqueryMsg load.php:9427
Uncaught TypeError: Cannot read property 'options' of undefined GmapFunc:255
Uncaught TypeError: Cannot read property 'tokens' of undefined GmapFunc:260

Can I try to catch the client-side error in load.php? I don't know how. Instead, I implemented the following server-side method to check whether the dependent modules actually exists:

static protected function checkAllModulesExists() {

		$allModules = array_keys( self::$mapModules );
		foreach ( self::$mapModules as $moduleName => $moduleDefinition ) {
			if ( !array_key_exists( 'dependencies', $moduleDefinition ) ) {
			if ( is_array( $moduleDefinition['dependencies'] ) ) {
				$allModules += $moduleDefinition['dependencies'];
			} else {
				# We do not check for multiple matches in values:
				# it would only decrease performance in this case.
				$allModules[] = $moduleDefinition['dependencies'];
		$nonExistantModules = array_diff(
		if ( count( $nonExistantModules ) > 0 ) {
			throw new MWException( 'Cannot find requested module(s): ' .
				implode( ',', $nonExistantModules ) .
				' in ' . __METHOD__


Which produces the following page message, at least (that is more informative than Chrome console message):

Cannot find requested module(s): mediawiki.jqueryMsg in GMFn::checkAllModulesExists

It would be nice if ResourceLoader itself checked the dependencies of added modules.

Version: 1.18.x
Severity: normal
Whiteboard: aklapper-moreinfo

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz37013.
bzimport created this task.Via LegacyMay 22 2012, 9:07 AM
Krinkle added a comment.Via ConduitMay 27 2012, 11:20 PM

Modules can be dynamically registered. This should be checked in mediawiki.js instead.

I believe this has been fixed in 1.19 or 1.20, could you confirm?

bzimport added a comment.Via ConduitMay 28 2012, 6:18 AM

questpc wrote:

I think Extension:UploadWizard also was using this module and it should be supported in 1.18.2 as well.

Is there a graceful way of catching these errors at client side in 1.20? However, 1.20 includes the forementioned module.

Aklapper added a comment.Via ConduitMay 17 2013, 2:16 PM

(In reply to comment #1)

Modules can be dynamically registered. This should be checked in mediawiki.js
instead. I believe this has been fixed in 1.19 or 1.20, could you confirm?

Dmitriy: Still running 1.18, or have you upgraded in the meantime?
If the latter, cxould you answer above question?

bzimport added a comment.Via ConduitMay 17 2013, 2:55 PM

questpc wrote:

Andre, MediaWiki is unpopular framework here in Russia. Our education system receives much smaller financing comparing to first world countries. Grants and charities are also very small, infrequent and hard to get. Non-commercial work is self-prohibitive because the life is expensive and wages are small (not in Moscow, at least). So I was not getting enough of freelancer MediaWiki job. Thus I was forced to move to Drupal then to my own framework. Sometimes I do small MediaWiki work but not so often and I lost deep knowledge of MediaWiki internals I had back in 1.15-1.17 times (API, FileRepo, early versions of ResourceLoader).

But of course previous lack of good scripting and lack of VisualEditor also contributed to low popularity of MediaWiki here in Russia. Hope it will get more popular again.

The site is now running 1.22wmf1. It was not my personal site but a freelancer job.

Aklapper added a comment.Via ConduitAug 14 2013, 4:09 PM

I see... Pity.
As we cannot retest, closing as per comment 1.

Add Comment