ResourceLoader/Migration guide for extension developers

Jump to navigation Jump to search

Most code written prior to MediaWiki 1.17, the introduction of ResourceLoader, should continue to work, there are some issues that are specific to the architecture of the system which may need to be resolved.

Crash-course: How to use ResourceLoader[edit]

Review resources/Resources.php for more examples of module registration and includes/OutputPage.php for more examples of how to add modules to a page.

For now let's start with how to register a module:

Registering a module[edit]

To make your resources available to the loader, you will need to register them as a module, telling ResourceLoader what you want to make available and where the files are. Check out ResourceLoader/Developing with ResourceLoader#Registering to learn how to do that.


You can access messages specified in your resource module using the mw.message() method. This returns a Message object whose output formats can be specified as described here. Example:

alert( mw.message( 'myextension-hello-world' ).plain() );

mw.message() can accept multiple arguments, with additional arguments being passed to the message function named in the first argument (exactly in the same way as with server-side message functions):

alert( mw.message( 'myextension-about-me', myName, myTitle ).plain() );

Inline JavaScript[edit]

In previous versions of MediaWiki, nearly all JavaScript resources were added in the head of the document. With the introduction of ResourceLoader, JavaScript resources are now (by default) loaded at the bottom of the body.

The motivation for this change has to do with the fact that browsers block rendering while a script resource is downloaded and executed (this is because a script can do almost anything to the page). By placing scripts at the bottom, the entire page can be loaded before any scripts are executed, ensuring that all stylesheets and images referenced by the HTML content as well as the CSS can be queued before the browser pauses to execute scripts, thus increasing parallelism, and improving client-side performance. This also ensures readers get earlier access to the articles and start reading.

A side-effect of this change is that scripts that have been injected arbitrarily into the different parts of the body can not depend on functionality provided by regular scripts (which are loaded at the bottom). It may be possible to improve backwards compatibility in the future, but there are no specific plans to do so at this time. We recommend to do javascript bindings from the modules rather than inline.

As of MediaWiki 1.18 there are multiple load queues in ResourceLoader (symbolically named "top" and "bottom"). Modules can set their "position" property (in $wgResourceModules ) to one of these to force loading in either queue. A good use of a "top" module is styling HTML content generated by PHP. The mediawiki and jquery module are loaded from the top by default and can always be used. The queues and positions were removed in MediaWiki 1.29 (phab:T109837), and everything is now at the "top".

Configuration variables[edit]

If you used to insert javascript like:

var wgFoo = "bar";

You can now use resource loader to add your variable as a config variable. If the variable is the same for all pages and should be on all pages, use the ResourceLoaderGetConfigVars hook. Otherwise if the variable depends on the current page being viewed you can either use the MakeGlobalVariablesScript hook or if you have an OutputPage object, the addJsConfigVars method. Variables added can be accessed in javascript using mw.config.get( 'variable name' );

Troubleshooting and tips[edit]

Global scope[edit]

As the scripts are loaded at the bottom of HTML, make sure that all OutputPage-generated HTML tags are properly closed. If you are porting JavaScript code to ResourceLoader, make the default outer scope variable declarations explicitly use window as their parent, because the default scope in ResourceLoader is not global (e.g. not a window). Which means that code that previously became global by using var something in a .js file, is now local. It will only be global if you make it global, by literally attaching it to the window object with window.myProperty.

An even better approach (instead of attaching vars to window) is to convert the existing extension's JavaScript code to an object oriented structure. (or, if the code is mainly about manipulating DOM elements, make a jQuery plugin).

Suppose your current structure looks like this:

var varname = ..;

function fn( a, b ){

In order to keep it working with existing implied globals, replace implied globals with real globals (which it should already be):

window.varname = ..;

window.fn = function( a, b ) {

To actually port it to an object oriented structure, you'd write something like this:

mw.myExtension = {
  varname: ...,
  fn: function( a, b ) {

Special case of external libraries[edit]

If you are using an external JavaScript library, which is primarily maintained outside of MediaWiki extension repository, patching as suggested above is undesirable. Instead, you should create an extra JavaScript file where the required variables and functions would be bound via the references to window. Then, when registering ResourceLoaderFileModule you should pass both scripts in one PHP array:

'scripts' => array( 'ext.myext.externalCode.js', 'ext.myext.externalCode.binding.js' )

This will weld the two scripts together before throwing them into a closure.

ext.myext.externalCode.binding.js should contain assignment statements like this:

window.libvar = libvar;
window.libfunc = libfunc;

Some libraries autodetect their environment (AMD, node.js, browser, etc.) and can be mistaken in their choice because of the special environment of ResourceLoader. For instance, d3.v3.js (D3.js version 3) selects a node.js-like environment and exports its main variable d3 in module.exports (the issue doesn’t appear for d3.v4.js); in this case, d3.v3.js must have a binding file d3.v3.binding.js:

window.d3 = module.exports;

See also