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 resources/Resources.php for more examples of module registration and includes/OutputPage.php for more examples of how to add modules to a page.

If you are porting your extension to ResourceLoader, please add it to the list of ResourceLoader compatible extensions. The extensions on this list should also be useful as examples.

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

Registering a module
This section is a work in progress, updating since r77011

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.

Notice that we only list the dependency we directly need. Other modules such as jquery and jquery.ui will be automatically loaded to support jquery.ui.datepicker. Also notice that because this is a module provided by and related to an extension, the module name begins with "ext.".

Tip: Pass single resources as a string. Pass multiple resources as an array of strings.

Adding a module to the page
While building the page, if you want a module to be loaded before document ready, you need tell the OutputPage object to add one or more modules to the page.

Tip: Provide addModules with an array of module names if you want to load more than one.

OutoutPage::addModules adds the given the module name(s) to the load queue of the page. The client side loader will request all of the components for this module (scripts, styles, messages, dependencies, etc.) and load them. If your module contains a stylesheet that styles elements that are outputted by PHP as well as styles and/or scripts that insert content dynamically, then you should split the module into two separate modules. One for styling/enhancing the output, and one for dynamic stuff. The former module should have the "position" property set to "top", so that ResourceLoader will load it before parsing the rest of the HTML, preventing a FOUC (Flash of unstyled content). The other module doesn't need a "position" property and will simply be loaded asynchronously by the client, not blocking further parsing of the page.

Both should be added to the load queue in the same way, without repeating or forcing any particular loading style. This information is already in the module registry and the client will handle it accordingly. Usage of OutputPage::addModuleStyles should be avoided.

Loading a module dynamically
If the page is loaded, it's still not too late to get your module loaded on the client. You will just need to ask the  object to get it for you.

Tip: If you just want to load the module, and don't need to run any code when it arrives, you can just use.

Internationalization
You can access messages specified in your resource module using the  method. 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 loaded at the bottom of the body.

The motivation for this change has to do with the fact that most browsers will wait for scripts to load and execute before continuing to load the page. By placing scripts at the bottom, the entire page can be loaded before any scripts are executed, ensuring that all style sheets 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 in effect client-side performance.

A side-effect of this change is that scripts that have been injected arbitrarily into the body can not depend on functionality provided by 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.

Troubleshooting and tips
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 not local and is only global if you make it global by literally attaching it to the window object by using.

An even better approach (instead of chaning var to window, if needed) 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 is should already be):

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

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:

""