Talk:ResourceLoader/Core modules/Archive 2/Flow export

user.tokens

Declared to be available in 1.19, but present in 1.18. (rev:88554, May 2011). Check please. Greetings --PerfektesChaos 13:07, 29 November 2011 (UTC)

I tried to test this (on huwiki), but mw.user.tokens.get("editToken") returns "null". :( Any explanation is welcome. Winston 11:07, 22 January 2012 (UTC)

Browser restart fixed the pb. Strange. 89.133.63.54 13:30, 22 January 2012 (UTC)

{{sofixit}}. Looks like someone already did. Krinkle 13:38, 22 January 2012 (UTC)

"See a live example..." at the bottom -- followed the link and it says "404 - Cannot find file" 50.34.49.172 00:55, 13 July 2012 (UTC)

Fixed Helder 15:29, 23 July 2012 (UTC)

jquery.makeCollapsible does not work when logged in

Collapsible elements work for anons but when users login (including admin) it no longer functions. All elements default to expanded mode and the links for expand/collapse are no longer visible. Here is an example of the bug in action. Login is..

User: User Password: password

Then you can see how it no longer displays. I'm thinking the jquery.makeCollapsible script is not being loaded after login. Could this be due to a LocalSettings variable?

Thanks! 166.122.75.38 00:22, 10 March 2012 (UTC)

logged into the site, and either you guys solved it all by yourselves, or it's browser dependent. either way, it worked fine for me (chrome 18.0.1025.56 beta-m). קיפודנחש (talk) 22:07, 13 March 2012 (UTC)

Capitalization of module names

I was wondering if the names of the modules on (section names on) this page shouldn't be using the same capitalization which is defined at /resources/Resources.php.

For example, "mediawiki.api" is the module name which should be used on e.g. mw.loader.using, but "mediaWiki.Api" is what someone would need to use inside of a JS code to access what is defined on that module. Helder 16:49, 27 March 2012 (UTC)

I know what you mean. However this page primarily documents the code, not the module.

Main reason being that not all objects are in individual modules. Some modules provide multiple objects, others only extend existing ones.

Once we have migrated to a proper documentation system (RFC), we could include a piece of data showing which module(s) are required to use a function.

For now it is mainly documentation of the javascript code, not the module structure. But feel free to add that information :) Krinkle (talk) 18:00, 27 March 2012 (UTC)

I'd certainly like to move to autogenerated (parsed along the lines of Doxygen) documention too. But until that happens, this should in fact document the modules. That means there should be a section for every module listed in Resources.php. Within that section, we should document any objects added or extended.

We should also fix the capitalization and spelling whenever discrepancies are noted. Superm401 - Talk 21:39, 23 December 2012 (UTC)

@Superm401: Thanks for your recent reorganisation of the page. However a few minor points:

Your edits left the page in an inconsistent state. It used to be consistent. The section headings were capitalised after the javascript API they expose (e.g. Heading mediaWiki.Title is that way because the global variable is lowerCamelCase (window.mediaWiki) and the mediawiki.Title module defines mediaWiki.Title. These were not broken or discrepant.

You supposedly "fixed" some of them by changing them to their module namen and the result is an inconsistent mess where some are javascript identifiers, some are module names, and some are self-invented. Anchor links from other pages also stopped working properly (e.g. RL/DM#mediaWiki.Title no longer works).

Renaming headings like "api.get" to "mw.Api.get" introduced an incorrect and confusing image. Identifier "mw.Api.get" resolves to nothing. It is defined as "mw.Api.prototype.get". Referred to as "api.get" or "mw.Api#get" (where dot is a property, and hash a member of an instance, the constructed object from mw.Api) but not mw.Api.get since that is undefined.

Also don't include "?" or stuff "citation needed". If you're not sure, ask on the Talk page (this is not Wikipedia, we only deal with simple and verifiable facts).

I've fixed it now because it was easier to finish then to revert and let you fix it. Krinkle (talk) 03:44, 31 December 2012 (UTC)

It's a work in progress, and I appreciate you continuing it.

There actually were some inconsistencies before. In this revision, I noticed (but there could have been more):

• Some single-method scripts (mw.log) had nested headings while others did not (e.g. autoEllipsis, placeholder).
• Some method headings had context (e.g. api.get) while others did not (e.g. addCSS).
• Some method names weren't even headings (still true).
• There was one random example heading, which I see you fixed.

Note that I've been adding modules and other information as well, which is part of what has been taking the time. There are still some missing modules. I may add them when I have an opportunity, but if I am able to get auto-generated documentation working, it will not be necessary.

I suggest we expand the TOC depth, perhaps to 4. I think there are some important methods (e.g. log, the loader methods) that are not shown currently. I realize this will make the TOC longer, but I think it's worth it.

Anyway, I'm glad we have been able to make it more usable. Superm401 - Talk 22:56, 1 January 2013 (UTC)

Separator Character

I was surprised to see an error in this class related to separator characters. It started when I received the following error message on a Windows XP machine running WAMPServer: ResourceLoaderFileModule: script file not found: "C:\wamp\www\wiki\extensions\Comments/Comment.js"'

I looked at the ResourceLoaderFileModule, and saw the following code for getLocalPath:

protected function getLocalPath( $path ) { return "{$this->localBasePath}/$path"; }

Being somewhat new to PHP development, I was surprised to see that "/" as opposed to a constant. But then I read the following article: http://alanhogan.com/tips/php/directory-separator-not-necessary

So now I'm very puzzled. If the separator is not necessary, why is it that the script file cannot be found? I changed the ResourceLoaderFileModule to use "\\" and I solved my immediate problem, but I would have thought this to be a non-issue as the PHP note was from 2008. Any suggestions would be helpful. 71.191.112.194 02:46, 23 April 2012 (UTC)

mw.log

The main page presently explains: "Calling this either pushes the messages to console if its available and have a logging facility, or adds it to an #mw-log-console if not (the element is created on the first call) [...] Note that different browsers and extensions may enable or disable different consoles and different logging facilities, and that they may or may not be visible even if they are used for logging purposes."

Please add some information to the documentation how visibility is being managed. Presently, some standard code is adding log messages, e.g. jquery.makeCollapsible output "Found custom collapsible:" and the id of the key. This is invisible on Chrome and Firefox (where a real log console exists), but is visible to all users of Internet Explorer (where a div is appended to the end of the wiki page). I assume that not all users of all wikis shall see this, so that the style for this div should be set to display:none - but it seems odd to require this to do manually in all instances of the mediawiki software (outside WMF). G.Hagedorn (talk) 13:15, 22 June 2012 (UTC)

You shouldn't try to "hide" the log simulator. Instead, don't enable it in the first place on a production wiki.

The above description of mw.log only applies to when the wiki is in debug mode. In production mode, mw.log is a no-op (empty function that doesn't do anything, no matter the browser).

In debug mode it is desired to have it be visible, there should be no need to hide it in Internet Explorer - in debug mode. Krinkle (talk) 03:13, 24 June 2012 (UTC)

Thanks for the explanation! With "debug mode", do you refer to Manual:$wgResourceLoaderDebug, correct? But when we need to investigate javascript-related problems, many of which are content- and template related, we cannot duplicate all our wikis all the time. This may be different in the WMF case. For us it is a huge difference whether a log is invisible or is confusing all current users. I believe it would be better if plain-visible debug information could be turned on or off separately. Or at least the minimization in non-debug mode could be turned off separately?

I added "In default mode javascript will be not minimized, and many message may be visible directly on the screen to all users (if using Internet Explorer)." to Manual:$wgResourceLoaderDebug, please correct if misleading. G.Hagedorn (talk) 22:38, 23 July 2012 (UTC)

(maybe too late - added for future generations):

for debugging when $wgResourceLoaderDebug is not set, you can still put the page in "debug mode" by adding &debug=true (or ?debug=true) to the address line of the page. קיפודנחש (talk) 15:12, 21 August 2012 (UTC)

customtoggle for different states?

How would I go about making different customtoggles for the two states (expanded or collapsed) a section can be in?

Does this require custome js, or is there already a way to do it using default wikimarkup? Ashimema (talk) 11:19, 8 October 2012 (UTC)

filemtime() stat failed error in resourceloaderfilemodule.php

This post by Krinkle was moved on 2013-01-03. You can find it at Project:Support desk/Flow/2012/04#h-filemtime()_stat_failed_error_in_resourceloaderfilemodule.php-2012-04-08T05:10:00.000Z. Krinkle (talk) 06:18, 3 January 2013 (UTC)

Can't tell what is a module name and what not

From this documentation I can't tell if I should write

• mw.loader.using('mediawiki.user.options', fn),
• mw.loader.using('mediaWiki.user.options', fn),
• mw.loader.using('mw.user.options', fn),
• mw.loader.using('user.options', fn), maybe
• mw.loader.using('mediawiki.user', fn) or possibly
• mw.loader.using('options', fn) (I'm pretty sure I saw this somewhere).

In short, the list is a mess. I can't tell the difference between module names and function names that are part of a module. Or is this the same? Can I use 'mediawiki.util.addCSS' as a module name even if it is a function? I can't tell. My proposed solution is to mark function calls with mediaWiki.a.b() and module names with 'mediawiki.a.b' (without the color, of course).

Also from what I know mw is a shortcut for mediaWiki and shouldn't be used in this list except for a single hint in the introduction. Or the other way around. But don't mix it, please.

Also I'm confused because it seems many of these mw.loader.using() calls are pointless. Things like mw.user.options.get() or mw.config.get() work anyway, everywhere. Under what circumstances do they not work? How to replicate these circumstances? TMg 17:18, 7 January 2013 (UTC)

Bottom line, if it's a level three heading, it's a module. In the TOC, that's every heading like "d.dd some.module" (example: "1.4 mediawiki.api"). The number (1.4) is generated by the TOC, and doesn't matter except to tell you the heading depth. In the wikitext source, these have three equals signs on each side.

user.options is a little bit of an odd man odd in terms of the naming convention. However, you can see there is such a heading (currently "1.2 user.options"), and "user.options" is the module.

You can only use using with a module name, so you can not do things like using('mediawiki.util.addCSS'). Also, 'user.options' only works everywhere because something else on the page is depending on it. You get lucky like this sometimes. However, I try to explicitly depend on everything I need except two modules, 'mediawiki' and 'jquery'. Those two are always present.

The module names do look as you proposed in the TOC (except for quotes). I'm fine with adding () to the method headings. However, I don't want to invest too much work into this, since the goal is to replace it with auto-generated documentation relatively soon. Superm401 - Talk 01:44, 8 January 2013 (UTC)

It would be very helpful to make the headings something like "Module <code>"mediawiki.api"</code>" to make things clear. Currently I can't tell the difference between the heading levels. They all look the same except for a slightly different font size. Even worse, things like "mediaWiki.config" are neither a module nor a function. "mediaWiki.config()" would be wrong. Please remove such stuff if it's neither an usable function name nor an usable module name. It doesn't add anything. It's just confusing. Also an overview of the dependencies would be helpful.

I'm not a friend of the resource loader stuff. It makes things so insanely complicated without adding much use. (It worked for years. Why change it? Do our Internet connections get slower?) Sometimes I consider the resource loader "broken by design". If no average user is able to write valid user scripts any more something must be broken. TMg 22:36, 8 January 2013 (UTC)

That heading would break existing links, but you could do it if you add {{Anchor }} with the old values. You kind of have a point about mediaWiki.config, but it is an object and needs to be documented somewhere.

The dependencies are in Resources.php, but generally you don't need to worry about that. You just depend on what you need. If you need to add stuff to the watchlist, you depend on mediawiki.api.watch. You don't need to worry about what it depends on.

I think the ResourceLoader is quite useful. There are two big reasons:

• It handles minification and concatenation quite well, and some MediaWiki message (for i18n) cases (I am working on improving this).
• It handles dependencies properly, and if you're writing an extension, or in MW core, the dependency interface is nice (you just specify an array of dependencies in a module definition). It is currently a bit of a pain for user scripts, though you can still pass an array of dependencies to using if there's more than one you need at the same time. Improving the user script and gadget experience is an important goal.

Since the good ol' days, MW has added a lot of useful scripts with various dependency chains. Further, other major sites have gotten faster through techniques like minification, and we need to do the same. RL also has other useful side features like flipping CSS automatically for right-to-left languages. Superm401 - Talk 18:56, 9 January 2013 (UTC)

Thank you very much for the nice answer. After fighting every possible problem while maintaining my user script (which is also used by many other users) I think I understand most parts of that crazy nesting hell. (Except for the ready() stuff. I would really like to understand that.) Everything there is required for some reason: Make sure the options are loaded. Check one of the options. If it's enabled make sure an other module is loaded. Wait for it (I think that's what the ready() does but I don't understand how). Apply the button.

However, to make this usable for an average user there needs to be a simplified way to write it like this without loosing any functionality:

import('user.options');
if (mw.user.options.get('usebetatoolbar'))
{
    import('ext.wikiEditor.toolbar');
    $('#wpTextbox1').wikiEditor('addToToolbar', /* … */);
}

TMg 20:49, 4 February 2013 (UTC)

first, you don't import "user.options", but rather the module: "mediawiki.user", which, in turn, makes the *object* mw.user.options available to you.

second, because these resources are pulled from the web, it is usually not such a great idea to serialize it the way you suggest. in principle it *is* possible to do it the way you outlined (one would have to write a "synchronized import" function, which is totally possible), but it would mean that the browser will "freeze", and do nothing else (it might be responsive to user input, but it won't be able to execute any other JS stuff) while the browser goes and pulls the module off the server, however long that takes.

in the current mode (using the "using" method), the browser sends a request to the server to pull the module "mediawiki.user", and while the server prepares and sends the module, the browser is free to go and play elsewhere and do other stuff, such as figuring out what *else* is needed, and ask for it. once the module arrives from the server, the "using" triggers execution of the inside function.

think about it like this: javascript is single-threaded. the "using" and similar methods (such as "ready") allow it to pretend to be multithreaded, in the sense that while waiting for something to happen, it can go and do other stuff instead of wait idly.

peace. קיפודנחש (talk) 00:08, 5 February 2013 (UTC)

I'm sorry but I do not care. All I want to do is to add a damn button to a toolbar. It has to wait anyway no matter how this stuff is loaded. This was a single (!) line of code with the old toolbar. Add button. Done. The current copy and paste garbage required to do the same is simply insane. It's not my job to put code that clearly belongs to the MediaWiki core into my user script. TMg 17:56, 15 February 2013 (UTC)

mw.Api

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();
api.get('foo');
api.get('bar');

(which seems to work fine, by the way) 124.181.108.69 10:38, 25 March 2014 (UTC)

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 https://doc.wikimedia.org/mediawiki-core/master/js/#!/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). Superm401 - Talk 22:12, 26 March 2014 (UTC)

Alright, that seems useful in some cases. Thanks. 124.181.106.190 11:55, 28 March 2014 (UTC)

Table in German Mediawiki 1.22

As far as I can see, when checking the output(CTRL/U), the tablesorter module is not loaded. Is there a switch, to turn it on? This is my table class="wikitable sortable float-left"

Thank you for your attention [[User:Bmrberlin| Bernd M.]] (talk) 10:22, 8 September 2014 (UTC)

There is no switch; the module will be loaded automatically if required by server-generated page.

You might want to contact w:de:Wikipedia:Technik/Werkstatt and provide detailed information on which page this happened, and which table.

Greetings PerfektesChaos (talk) 08:50, 9 September 2014 (UTC)

mw.loader.using()

The doc states there are three parameters, of which two are callbacks (succes and fail). But the example uses a method instead of the second parameter. Is there a method for the third parameter as well? -- [[User:Edokter]] {{talk}} 14:47, 8 March 2015 (UTC)

Read the documentation. mw.loader.using returns a promise. 124.181.128.160 01:21, 9 March 2015 (UTC)

jquery.jStorage saved data lost on logout

When user logs out of Wikipedia and in again, all data that was saved in browser locally through jquery.jStorage module is gone. Try the example code below. It saves Date() values at the page loading time and displays all saved values. Everything is perfect until you log out.

mw.loader.load( 'jquery.jStorage' );
$(document).ready(function(){
	var value = new Date();
	var key = value.getTime();	
	$.jStorage.set( key, value.toString() );
	var jSindex = $.jStorage.index();	
	var i;
	var txt = "You have loaded the script at following times:\n\n";	
	for	(i = 0; i < jSindex.length; i++) {
		txt += (i + 1) + ". " + $.jStorage.get(jSindex[i]) + ",\n";
	}
	alert (txt);
});

Cumbril (talk) 06:03, 17 March 2015 (UTC)

oojs

Should oojs be included in the list, or is it non-default? Danmichaelo (talk) 16:16, 4 October 2015 (UTC)

Yes, it should be included in the list, it has been included in MediaWiki core since 1.23. Legoktm (talk) 04:50, 5 October 2015 (UTC)

Done Mattflaschen-WMF (talk) 21:15, 5 October 2015 (UTC)

Collapse and Expand buttons do not show in mw-collapsible

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 (talk) 22:11, 26 October 2015 (UTC)

This appears to be an issue in the Wikitext/Preview tab only, so I have disabled the WikiEditor preview. Ken Roy (talk) 10:46, 6 November 2015 (UTC)

Duplicating documentation

Modules such as mediawiki.feedback 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)? Prtksxna (talk) 12:23, 17 November 2015 (UTC)

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). Od1n (talk) 16:54, 11 October 2018 (UTC)

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 doc.wikimedia.org, 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. Krinkle (talk) 18:23, 11 October 2018 (UTC)

Code in ResourceLoader/Core modules#mw.Api#parse

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I tested this code on Wiktionary and it doesn't work. — Eru·tuon 21:22, 23 May 2017 (UTC)

Can you be more specific about what you tried and what isn't working? I just tested it and it works for me. Legoktm (talk) 21:28, 23 May 2017 (UTC)

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: . — Eru·tuon 23:06, 23 May 2017 (UTC)

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:

mw.loader.using( 'mediawiki.api.parse' )
.done( function() {
    new mw.Api().parse( {
        // like the example.
    });
}); // 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.

peace. קיפודנחש (talk) 22:02, 23 May 2017 (UTC)

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... — Eru·tuon 23:12, 23 May 2017 (UTC)

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.

peace. קיפודנחש (talk) 02:42, 24 May 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Is there any way to callback after using load?

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 Eduemoni (talk) 23:27, 11 January 2019 (UTC)

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. Od1n (talk) 01:52, 12 January 2019 (UTC)

Won't this work for you?

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

Jack who built the house (talk) 07:43, 12 January 2019 (UTC)

Or even shorter:

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

— Eru·tuon 10:14, 12 January 2019 (UTC)

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. »

Od1n (talk) 02:22, 13 January 2019 (UTC)

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. — Eru·tuon 10:15, 13 January 2019 (UTC)

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();
            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 (talk) 11:32, 13 January 2019 (UTC)

For the sake of refs'ing, this implementation has been introduced in this commit (T192623). Od1n (talk) 14:03, 13 January 2019 (UTC)

I also tried with asynch, await and .then() but I was informed that [As of April 2021] the JS syntax checker blocks use of ES6 in (i) gadgets, (ii) sitewide JS pages and (iii) user common.js page. So no `await` in `MediaWiki:Common.js`.

I would like to load into `MediaWiki:Common.js` 3 data from pages [MediaWiki:dataA.js], [MediaWiki:dataB.js], [MediaWiki:dataC.js] , then process these data. Clean, merge. Then create a dataviz. I need it to be sequential but I'm still not clear how to do so. As of now, this data are still undefined when my clean, merge, and dataviz code runs.

As for this ES6 issue, there is a hack consisting in storing the ES6 in the User namespace (ex: `User:.../something.js`), then you can use mw.loader.load() and it somehow work. Yug (talk) 18:34, 19 January 2022 (UTC)

You may also use mw.loader.getScript() (which, contrarily to jQuery.getScript(), wait for the loaded JavaScript to be executed):

mw.loader.getScript( '/w/index.php?title=MediaWiki:Slick.js&action=raw&ctype=text/javascript' ).then( function () {
    /* Callback */
} );

Internally, it uses jQuery.ajax(), just tweaking the options so that the HTTP cache is re-enabled. I had a look at jQuery source code some time ago, to confirm it is executing the loaded JavaScript before triggering the promise. Od1n (talk) 19:39, 21 May 2022 (UTC)

I'd like to clarify a confusion that was there initially, but has been addressed for good since 2022:

Whether you do:

$.getScript( url ).done( callback );
$.getScript( url, callback );
mw.loader.getScript( url ).then( callback );

In all cases, the script is guaranteed to be loaded and executed before the callback is called.

See jQuery issue #1207 for details / investigations.

The only difference is that mw.loader.getScript() passes an option cache: true to the internally used $.ajax(). Od1n (talk) 16:24, 16 November 2024 (UTC)

Access the API.edit.create function in MediaWiki 1.31.1

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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: https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Api.plugin.edit

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

Thank you,

-Don FlyDangerousO7 (talk) 19:10, 6 September 2019 (UTC)

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 (talk) 21:45, 6 September 2019 (UTC)

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
} );

Od1n (talk) 22:09, 6 September 2019 (UTC)

That worked exactly as excepted! Thank you for the help. :) 139.169.212.144 (talk) 15:18, 9 September 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Could we split the MediaWiki section somewhere?

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). Þjarkur (talk) 10:15, 22 October 2019 (UTC)

Heading selection

Rather than @Nardog edit-warring, I'd invite them to explain and discuss why they want to re-design this page with its maintainers. :-) Jdforrester (WMF) (talk) 14:56, 27 August 2020 (UTC)

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? Nardog (talk) 15:04, 27 August 2020 (UTC)

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 Ciencia Al Poder (talk) 11:40, 1 September 2020 (UTC)

This page does not provide a list of methods. That's what the API documentation is for. Krinkle (talk) 15:04, 4 September 2020 (UTC)

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

Is there any way to do this? Plantaest (talk) 07:30, 3 August 2021 (UTC)

No. Hidden gadgets can't be enabled/disabled in preferences. That's the whole point of hidden gadgets after all. Ciencia Al Poder (talk) 09:23, 3 August 2021 (UTC)

I have a question

Why is ES6 not supported in Gadgets and UserCommonJS? Zes M Young (talk) 05:35, 21 May 2022 (UTC)

See T75714. Legoktm (talk) 20:21, 21 May 2022 (UTC)

tipsy

tipsy was "deprecated" years ago, with no suitable substitute.

current doc recommends using "oojs", but i could not locate any oojs functionality pertaining to tooltips, IOW, no oojs class/object/api which can replace tipsy.

at the very least, i suggest removing this null recommendation from the doc.

if i missed something, and there _si_ some oojs things which can replace tipsy, please provide more precise link in the doc (and in any answer to this post).

thanks, peace - קיפודנחש (talk) 19:20, 5 August 2022 (UTC)

Please check PopupWidget and other Popup*-prefixed classes (docs). Peter Bowman (talk) 19:39, 5 August 2022 (UTC)

sorry, but popup is not adequate, or even inadequate, replacement for tipsy.

the main functionality of tipsy is handling the "hover" feature, i.e., responding to "mouseenter/mouseleave" events (with some timers intermingled), handling the display/hide of the tooltip based on mouse pointer location.

popup does not provide any support there, and in order to implement tooltip functionality, the programmer has to reimplement 80% of tipsy code herself, capturing the events and controlling the visibility of the popup.

IOW, popup can't be considered replacement for tipsy.

if i missed some key functionality of popup, and it can actually do some of what tipsy does, i will be very grateful to learn.

peace. קיפודנחש (talk) 20:04, 5 August 2022 (UTC)

I wouldn't say that implementing said logic is hard, but on the other hand I don't know what your specific requirements are. Here you can find a desktop-oriented gadget that registers hover events for an OOjs-ui tooltip. Peter Bowman (talk) 21:25, 5 August 2022 (UTC)

Anything relying on hover is fundamentally incompatible with mobile users, who are the majority of readers and a growing portion of editors (albeit still the smaller part). I don't expect there will be a hover-based functionality shipped. Please stop using them. Jdforrester (WMF) (talk) 20:33, 5 August 2022 (UTC)

unfortunately, mobile does not support hover.

that said, wikimedia projects do support "desktop only" features, some of which depend on "hover", e.g. "page preview" and "cite preview" features.

there are other desktop only features, including most project-specific gadgets, and having better tooltip tool is important.

i don't love tipsy, and would like to have a good ooui tool to replace it, so i don't have to re-implement it in each script or gadget that uses tipsy today.

peace קיפודנחש (talk) 02:08, 6 August 2022 (UTC)

We use Tipsy to provide mobile users with tooltips that are otherwise hidden to them. Instead of displaying a tooltip on hover, the tooltip is displayed when the user touches or taps the text that should display the tooltip.

For example, we have some tooltips created with this code:

<span class="explain" title="This is a tooltip">Text</span>

Desktop already displays a tooltip on hover. On mobile, users can tap the text to display the tooltip thanks to Tipsy. Text marked with class="explain" gets a dotted underline to give users a hint that there's some tooltip there.

The deprecation means it may be removed from MediaWiki core in the future. But I don't mind, because we've gadgetized the tipsy code as to not depend on this core feature. Of course, on a non-WMF wiki :) Ciencia Al Poder (talk) 11:46, 10 August 2022 (UTC)

mw.hook("wikipage.content")

I have a piece of code that's supposed to run every time Wikipedia Recent Changes is (semi)automatically refreshed (live feed / button press on new changes):

$(document).ready(function() {

if (mw.config.get("wgCanonicalSpecialPageName") === "Recentchanges") {

       mw.hook("wikipage.content").add(function (){

            /*...code to move some divs around...*/

            console.log("fired!")

       })

   }

}

This always seems to fire twice. My question is whether "wikipage.content change" applies only to content provided by the server, or does my div-moving-around also count as content change, triggering the hook for the second time. How can one prevent this from happening? Thnx. pon_or (talk) 22:10, 18 August 2022 (UTC)

You can see how it's done here:

1. sv:MediaWiki:Gadget-TruncateIPv6.js
2. sv:MediaWiki:Gadget-RecentChangesUnpatrolledPages.js
3. sv:MediaWiki:Gadget-RecentChangesSnabbraderingar.js
4. sv:MediaWiki:Gadget-rcexcludeuser.js Nirmos (talk) 03:00, 19 August 2022 (UTC)

Thank you very much, @Nirmos! For reference, this is what needs to be done (from example #4):

a) define a function that needs to be run when the page is loaded and when the mw-changeslist <div> (Recent Changes page) is refreshed:

function fireIt() {

/*...code to move some divs around...*/

console.log("fired!")

}

b) run the function within $(document).ready()

c) set up a mw.hook within $(document).ready() like this

mw.hook("wikipage.content").add( function (element) {

if ( element.hasClass( 'mw-changeslist' ) ) {

fireIt();

}

}); pon_or (talk) 08:53, 19 August 2022 (UTC)

Use mediawiki-core outside MediaWiki?

Can I use mediawiki-core JS library (mediawiki.*) outside MediaWiki's front-end environment? If possible, what do I need to configure before using it (like to be able to execute a POST request with token)? Plantaest (talk) 12:38, 28 September 2022 (UTC)

Executing POST requests with tokens doesn't need the mediawiki.* library.

Use native XMLHttpRequest objects from JavaScript, or utility libraries like jQuery against the MediaWiki api. Ciencia Al Poder (talk) 21:50, 29 September 2022 (UTC)

Is there a documentation for jquery.tablesorter?

The documentation link in "#jquery.tablesorter" section is unavailable. Is there a documentation for this module? HyperNervie (talk) 15:08, 17 January 2023 (UTC)

I've fixed the link. It points to the source code, which includes some comments with examples.

See also Help:Sorting Ciencia Al Poder (talk) 15:53, 17 January 2023 (UTC)

The documentation site seems to be broken

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

https://doc.wikimedia.org/mediawiki-core/master/js/

This page relies heavily on redirecting people to the JS docs but for me it remains stuck on the loading cogwheel. The console displays a 404 error. Pipsteer (talk) 11:42, 27 July 2023 (UTC)

It works fine for me. What page / resource is 404ing for you? Jdforrester (WMF) (talk) 11:48, 27 July 2023 (UTC)

Works for me, too Ciencia Al Poder (talk) 13:07, 27 July 2023 (UTC)

It was broken for me too but fixed itself when I opened the developer console. So some sort of a caching issue I think. Taavi (talk!) 13:29, 27 July 2023 (UTC)

Maybe it was being updated after a deploy, and you just hit the website at that precise moment :) Ciencia Al Poder (talk) 13:39, 27 July 2023 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Replacement for jquery.chosen

Per https://github.com/harvesthq/chosen, jquery.chosen is deprecated. Can Select2 be added as a replacement? It has much of the same functionality, plus the appearance is much more in line with OOUI. Ahecht (talk) 20:25, 2 June 2024 (UTC)

@Ahecht: We're probably going to want to drop it, rather than replace it; it's been unused in production code for a long while, except for any gadgets/scripts. Jdforrester (WMF) (talk) 15:22, 3 June 2024 (UTC)