Talk:ResourceLoader/Core modules

Jump to navigation Jump to search

About this board


Archive (until 2012)

mw.Api().saveOption() can't change value of hidden gadget option?

P.T.Đ (talkcontribs)

Is there any way to do this?

Ciencia Al Poder (talkcontribs)

No. Hidden gadgets can't be enabled/disabled in preferences. That's the whole point of hidden gadgets after all.

Reply to "mw.Api().saveOption() can't change value of hidden gadget option?"
Jdforrester (WMF) (talkcontribs)

Rather than @Nardog edit-warring, I'd invite them to explain and discuss why they want to re-design this page with its maintainers. :-)

Nardog (talkcontribs)

I just did, and you're the one who reverted it without explaining why.

The current TOC is highly user-hostile. There's not even a way to see the list of methods each module has.

Do you genuinely think it's superior? If so, care to explain?

Ciencia Al Poder (talkcontribs)

I actually like the display of 2 levels of headings instead of 1, to quickly jump to the relevant section. TOC is already floated to the right, so it's not very intrusive this way

Krinkle (talkcontribs)

This page does not provide a list of methods. That's what the API documentation is for.

Reply to "Heading selection"

Could we split the MediaWiki section somewhere?

Þjarkur (talkcontribs)

From the article's title it isn't obvious what information is contained here, and the functions of mw are not relevant to ResourceLoader. Wouldn't it be better to split it somewhere, maybe to Manual:JavaScript/mediawiki or Manual:mw? The information is also strangely split between this page and Manual:Interface/JavaScript (an article that could also do with a better name).

Reply to "Could we split the MediaWiki section somewhere?"

Access the API.edit.create function in MediaWiki 1.31.1

Summary by Jdforrester (WMF)

mediawiki.api.edit before 1.32.0

FlyDangerousO7 (talkcontribs)

I'm using the following mw.API call:

new mw.Api().create( 'Sandbox', { summary: 'Load sand particles.' }, 'Sand.');

I'm receiving an error: Uncaught TypeError: Cannot read property 'create' of undefined.

I believe that the edit module was a separate module pre-MediaWiki 1.32. I've been searching how to load the 'edit' module and access the create page function, but can't seem to find an example. I also tried to search for a git repository to backtrack the changes, but couldn't find a repository. The following documentation doesn't seem to support any other version of the API except for the newest MediaWiki version:!/api/mw.Api.plugin.edit

Does someone know how to use the create page function on MediaWiki 1.31.1?

Thank you,


Od1n (talkcontribs)

Try the following:

if ( mw.loader.getState( 'mediawiki.api.edit' ) !== null ) {
    mw.loader.load( 'mediawiki.api.edit' );

The test is to avoid triggering an error on MediaWiki 1.32 and following.

Od1n (talkcontribs)

A more complete snippet:

var moduleApiEdit = ( mw.loader.getState( 'mediawiki.api.edit' ) !== null )
    ? 'mediawiki.api.edit' // MediaWiki before 1.32
    : 'mediawiki.api';     // MediaWiki 1.32+

mw.loader.using( moduleApiEdit, function () {
    // your code
} ); (talkcontribs)

That worked exactly as excepted! Thank you for the help. :)

Is there any way to callback after using load?

Eduemoni (talkcontribs)

I am trying to load a js file under my wiki

mw.loader.load( '/w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' );

It loads the Slick jquery plugin, then after loading it I would like to use it as a gadget, where a wildcard number of classes can become a caroussel, however after loading it I am unable to use it, because the module is not loaded yet

Od1n (talkcontribs)

You could try the following:

mw.loader.implement( 'HackyCustomModuleRegistration', [ '/w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' ] );
mw.loader.using( 'HackyCustomModuleRegistration', function () {
    // ...
} );

However, the mw.loader.implement() method (code) is missing from the documentation, and is to be considered private.

Jack who built the house (talkcontribs)

Won't this work for you?

$.getScript( 'https://.../w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' ).done( function () {
    // your code
} );
Erutuon (talkcontribs)

Or even shorter:

$.getScript( 'https://.../w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript', function () {
    // runs if loading was successful
} );

Od1n (talkcontribs)

I thought it was a better solution… but from the jQuery.getScript() documentation (emphasis mine):

« The callback is fired once the script has been loaded but not necessarily executed. »

Erutuon (talkcontribs)

So if $.getScript(url, func) doesn't necessarily run the script before calling func, is the script run before func with $.getScript(url).done(func) or with the mw.loader version? I've used the $.getScript version that I posted without considering this issue; for whatever reason it worked fine.

Od1n (talkcontribs)

Digging inside the code of module mediawiki (and mediawiki.base), I found out the "load+execute script, then callback" code is actually very simple, see:

function addScript( src, callback ) {
    var script = document.createElement( 'script' );
    script.src = src;
    script.onload = script.onerror = function () {
        if ( script.parentNode ) {
            script.parentNode.removeChild( script );
        script = null;
        if ( callback ) {
            callback = null;
    document.head.appendChild( script );

A few notes about the code:

  • The two = null are for performance, to free memory (otherwise the objects would stay in memory forever)
  • The onerror event is not for request error, but for script execution error

So, I think the best solution would be to reuse the above snippet as standalone. Lightweight, no dependency of any kind :)

Od1n (talkcontribs)

For the sake of refs'ing, this implementation has been introduced in this commit (T192623).

Reply to "Is there any way to callback after using load?"
Prtksxna (talkcontribs)

Modules such as and mediawiki.util have documentation both on this page and on jsDuck. Should we remove the one here, link to the API docs, and copy over stuff that is missing there (or these three things in some other order)?

Od1n (talkcontribs)

I was about to post the same thing, about mediawiki.api.* submodules. Documenting the individual methods (mw.Api#isCategory, etc.) here is cluttering, cumbersome, unmaintained and outdated. Whereas we could link to specific API pages (category, etc.) which is simple to do, more convenient to read on jsDuck, and always up-to-date. Ping Krinkle (by the way, I've done a handful of edits on this page today).

Krinkle (talkcontribs)

Yeah, any outdated or duplicated documentation here is fine to remove. I've been doing that for years, but it's a slow process.

If you find any method/class documentation or usage examples that missing from, they should be added there before removing here.

If you find any migration instructions on this page that are missing from RL/MGU, they should be added there before removing here.

Reply to "Duplicating documentation"
Erutuon (talkcontribs)

I tested this code on Wiktionary and it doesn't work.

Legoktm (talkcontribs)

Can you be more specific about what you tried and what isn't working? I just tested it and it works for me.

Erutuon (talkcontribs)

I copied the code from the above link verbatim into the Wiktionary user script sandbox, and called mw.notify on the return value. Error in the console: Uncaught TypeError: api.parse is not a function.

קיפודנחש (talkcontribs)

note that even though the code says

new mw.Api();

it's not enough to load module mediawiki.api: you need to load mediawiki.api.parse, like so:

1 mw.loader.using( 'mediawiki.api.parse' )
2 .done( function() {
3     new mw.Api().parse( {
4         // like the example.
5     });
6 }); // using..done

note that loading this module, will automatically load its dependencies i.e. mediawiki.api, so you don't have to load it explicitly, though it won't harm anything to do so anyway.


Erutuon (talkcontribs)

Thanks! That solved the problem. I'm puzzled, because I had loaded mw.api, but the function parse was still not present in the mw.Api object...

קיפודנחש (talkcontribs)

mediawiki.api has several such sub-modules, e.g., edit, watch, options, and some more (and prolly more to come).

each brings some specific set of functions, to make the interaction with specific area of the api more convenient to use.

to use them, you need to load the one you need specifically. loading any of them pulls mediawiki.api with it.


Collapse and Expand buttons do not show in mw-collapsible

Ken Roy (talkcontribs)

I am testing an upgrade of MW from 1.16.5 to 1.23.10. Previously we used ToggleDisplay2 to Collapse or Expand text sections on a page. I am trying to use the jQuery:makeCollapsible replacement, but I am not getting the [Collapse] and [Expand] button links.

What am I doing wrong? Do I need to add anything the MediaWiki:common.js? or to LocalSettings.php for the jQuery:makeCollapsible to work?

Ken Roy (talkcontribs)

This appears to be an issue in the Wikitext/Preview tab only, so I have disabled the WikiEditor preview.

Reply to "Collapse and Expand buttons do not show in mw-collapsible"
Danmichaelo (talkcontribs)

Should oojs be included in the list, or is it non-default?

Legoktm (talkcontribs)

Yes, it should be included in the list, it has been included in MediaWiki core since 1.23.

Mattflaschen-WMF (talkcontribs)


Reply to "oojs" (talkcontribs)

Can anyone explain why this is a constructor? As far as I understand, it's just a convenient wrapper for $.ajax, which isn't a constructor.

Also, what is the correct way to use this when there's multiple requests? Do I have to make a variable for each request (lest jshint whine at me for using new for "side effects"), or can I just use the one? Eg:

var api = new mw.Api();

(which seems to work fine, by the way)

Mattflaschen (talkcontribs)

The class is a wrapper around $.ajax. However, one of the pieces of functionality it adds is being able to store options that apply to all requests using the object (unless overridden by the individual request). See!/api/mw.Api . Your example above is not using new for side effects. In fact, the constructor really doesn't have side effects. It creates a mw.Api object, but to use that object for a network request, you need to call further methods (which the example above does).

This post was posted by Mattflaschen, but signed as Superm401. (talkcontribs)

Alright, that seems useful in some cases. Thanks.

Reply to "mw.Api"