ResourceLoader/Developing with ResourceLoader

This is a quick walkthrough about the key points you need to understand to develop in MediaWiki core or an extension with ResourceLoader.

Registering

 * See also Manual:$wgResourceModules

In order for all the ResourceLoader features to function properly it is required to register modules under a symbolic name. We do that by adding the module definition to (if you're writing an extension), or to add the array to ./resources/Resources.php (if you're working in core).

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 (in this example) ext.myExtension is a module provided by and related to an extension, the module name begins with " ".

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

@embed

 * See also ResourceLoader/Features

The  annotation triggers the Data URI embedding feature of ResourceLoader. Small images (up to 24kb per image) referenced with this annotation will be automatically embedded by ResourceLoader.

@noflip

 * See also ResourceLoader/Features

To disable the flipping functionality for one CSS declaration or on an entire ruleset, use the  annotation:

For example:

Module structure

 * Work in progress

Two modules for most extensions. A module to be loaded from the containing styles and/or scripts that need to run as soon as possible. This module should generally be a small as possible and be used to:
 * Top module
 * Style output by PHP
 * Insert or modify elements that change the location of anything above the "the fold" (such as inserting a banner that pushes the page down, or a sidebar widgets that pushes another sidebar portlet down, or a content action tab that causes a change in the position of other tabs)


 * Bottom module (default)
 * Insert or modify elements that are not visible right away (e.g. binding autocompletion to a form element or inserting a small absolutely positioned widget)
 * Anything else

Toggle debug mode
ResourceLoader supports complex client-side web applications in production and development environments. As these different environments have different needs, ResourceLoader offers two distinct modes: production mode and development mode (also known as "debug") mode.

Development mode is designed to make development as easy as possible, prioritizing the ease of identifying and resolving problems in the software over performance. Production mode makes the opposite prioritization, emphasizing performance over ease of development.

It is important to test your code in both development and production modes. In day-to-day development, most developers will find it beneficial to use development mode most of the time, only validating their code's functionality in production mode before committing changes.

Learn more about debug mode at ResourceLoader/Features.

Server-side errors appear in comments
ResourceLoader reports PHP exceptions in JavaScript comments. This can mean that if there's a failure in PHP, unrelated JavaScript code reports an error, because the functionality it depends has been replaced by a comment containing the error. You should view the source of loaded modules when debugging an error to see if it includes PHP errors.

Breaking cache
When making frequent changes to code and checking them in a browser, the caching mechanisms designed to improve the performance of web-browsing can quickly become inconvenient. When developing on a system which is not making use of a reverse proxy such as Squid or Varnish, you only need to force your browser to bypass its cache while refreshing. This can be achieved by pressing CTRL+F5 in Internet Explorer, or holding the shift key while clicking the browser's refresh button in most other browsers.

If you are developing behind a reverse proxy, you can either change the values of $wgResourceLoaderMaxage or use ?debug=true to bypass cache since is fixed.

Good examples
The following is a list of MediaWiki extensions which take advantage of ResourceLoader functionality and are known to be a good example of ResourceLoader integration.


 * Extension:ArticleFeedback
 * Extension:Vector
 * Extension:WikiEditor
 * Extension:FancyBoxThumbs

Server-side
While building the page, if you need a module to be loaded, you need tell the OutputPage object to add one or more modules to the page by calling the  methods and passing one or more (variadic) arguments (such as " ", " " or " ")

adds the given 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 correctly. 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" (in the module definition in ), 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.

If you have CSS that should be loaded even when JavaScript is disabled, you can add it to the page with  which uses standard link CSS tags. You should probably keep this CSS in a separate ResourceLoader module to avoid confusion.

Client-side (dynamically)
If you only need a module in a certain scenario of the user interface, you could instead create a small init module (that is loaded server side), and from there use JavaScript to kick-off the load of the rest of the module when necessary. Use the  object for this. To access functions and variables defined in the module's scripts from the callback scope — they need to be made public, i.e. declared in the  object.

Module body:

Usage:

If you just want to load the module, and don't need the callback, you can use  instead.

Tip: You can combine the two approaches. For example, if you put up a jQuery UI dialog after an AJAX request, you can call  right after you fire off the request so the two load in parallel, then wrap the code that uses $.dialog in.