Page MenuHomePhabricator

"importScriptURI is not defined" with monobook skin
Closed, ResolvedPublic

Description

http://commons.wikimedia.deployment.wmflabs.org/wiki/File:P14.png?useskin=monobook&debug=true reveals the following on the JS console: "importScriptURI is not defined"


Version: 1.20.x
Severity: normal

Details

Reference
bz33669

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:08 AM
bzimport set Reference to bz33669.
bzimport added a subscriber: Unknown Object (MLST).

I don't get this on my dev wiki, but I do get the other 2 errors..

I *think* it may have something in the Gadgets .... testing.

This is/was because of http://commons.wikimedia.deployment.wmflabs.org/wiki/MediaWiki:Monobook.js?useskin=monobook

importScriptURI and importScript aren't supported by natively MediaWiki anymore. But http://commons.wikimedia.deployment.wmflabs.org/wiki/MediaWiki:Common.js tries to emulate them.

Since mw.loader.util is undefined when http://commons.wikimedia.deployment.wmflabs.org/wiki/MediaWiki:Common.js is loaded, I wrapped a loader-call around the whole js.

This caused that common.js-code was executed after monobook.js; thus importScriptURI & Co. were undefined.

So there is the question whether it is intended that mw.util is initialized after common.js is loaded and why mw.util.$content is still null despite all code is wrapped inside the loader-module.

mw.util should be loaded on top of everything, so there definitely seems to be a ResourceLoader related problem. I get several undefined errors for various modules and plugins (e.g. $.cookies) on the enwiki deployment.

Reopening this; Wrapping common.js in mw.loder is horrible kludge, and the loading order of common > skin JS should not be changed.

Spoke too soon.

  • This bug has been marked as a duplicate of bug 33711 ***