ResourceLoader/Migration guide for extension developers

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
Review for more examples of module registration and  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
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 to learn how to do that.

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

""

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):

""

Inline JavaScript
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 ) 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  and   module are loaded from the top by default and can always be used.

Configuration variables
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 accesed in javascript using

Global scope
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  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  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.

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:

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

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

Special case of external libraries
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:

""

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

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

""

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  in   (the issue doesn’t appear for d3.v4.js); in this case, d3.v3.js must have a binding file d3.v3.binding.js:

""

Example with full description
For a quick example of howto use Resource Loader to integrate the rare documentated jQuery features of MediaWiki, see Extension:FileSystemListing