Last modified: 2012-01-14 10:41:05 UTC
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"
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.
logged out on chrome, I see the error. logged in with all gadgets disabled, I see the error. I see it with gadgets disabled on http://commons.wikimedia.deployment.wmflabs.org/wiki/File:Javascript-wikibooks-pt.pdf?debug=true&useskin=monobook but not on http://commons.wikimedia.deployment.wmflabs.org/wiki/File:Javascript-wikibooks-pt.pdf?debug=true
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 ***
