Talk:ResourceLoader/Migration guide (users)

Minifying central gadgets

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.

---

Isn't better to change the mw.loader.load commands to get the gadgets through resource loader, so that they would be minified? Compare:

• http://bits.wikimedia.org/www.mediawiki.org/load.php?modules=ext!gadget!CodeEditor
• http://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-CodeEditor.js&action=raw&ctype=text/javascript

What do you think? Helder 23:46, 5 July 2011 (UTC)

Thanks, I've seen your efforts and help with the cross-wiki gadget mess we currently have.

Cross-wiki load.php requests are, however, discouraged as they can and will cause several undocumented behaviors which should not be dependent on and bugs that will not be fixed (since it's not an official feature).

ResourceLoader 2.0 will introduce the concept of using "Shared gadgets" from a declared "Foreign Gadget Repository" (like Commons is for files) which will do this much nicer and natively, thus removing the need to have a 1-line gadget importing it from another wiki.

Untill RL2.0 is ready, I recommend not wasting time with temporary solutions that are not supported and may break at any time. The legacy solutions currently around are no worse than before ResourceLoader made it's introduction and they will continue to work for a while, so I'd say stick to whatever it is now (such as action=raw). Krinkle 19:50, 6 July 2011 (UTC)

Ok then. Do you know in which version of MW this will be available?

If it will take some time until its release, it may be worth to replace the live version of the shared gadgets by its minified version, so that users can get a smaller amount of code for these gadgets while this is not available by default. E.g. for commons:MediaWiki:Gadget-HotCat.js, the Google Closure Compiler would save 37.90% off the gzipped size if we select the option "Whitespace only" and 50.68% in the advanced mode (although in this case it displays 86 warnings which may need to be addressed). Helder 13:53, 11 July 2011 (UTC)

We don't use the Google Closure Compiler but the minifier in ResourceLoader (based on Paul Copperman's JavaScriptMinifier).

Compare:

• raw
• production module Krinkle 21:37, 11 July 2011 (UTC)

Yes, but since the "production" version of the code is only sent to the users which are on the source wiki (not to people who enable a "one line gadget" on other wikis), I was suggesting to do something similar to what you do on RTRC.js and its -dev.js version, i.e., to save the minified version directly in the wikipage which is being used globally, so that we have a stopgap until ResourceLoader can be used to generate it directly. And for that purpose, the minifier we use can be anyone one available. Helder 17:23, 12 July 2011 (UTC)

You asked in which version of MW the new system will be available and were proposing to use Google Closure Compiler, obviously we're not talking about what's currently live on Wikipedia.

When central gadgets (or "Global gadgets" or "Shared gadgets") are ready, every use of them on any wiki will be "production". There will not be any one-line gadgets. Krinkle 10:53, 16 July 2011 (UTC)

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

From IRC to think about - Must user-scripts add a dependency to mediawiki.legacy.wikibits?

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'd like to add some information to mw: ResourceLoader/Migration_guide_(users) - "If I use importScript in my userscript, do I have to do mw.loader.using('mediawiki.legacy.wikibits', function() { /*code here*/ } or can I simply use it?"

Imagine I want to use importScript in my User:Rillke/Common.js

Will it be defined for sure or should I ensure mediawiki.legacy.wikibits is loaded by "using mw.loader.using('mediawiki.legacy.wikibits', function() { importScript(...) }"

If so, add to ResourceLoader/Migration guide (users)#Migrating user scripts:

---

But keep in mind they require the mediawiki.legacy.wikibits-module.

mw.loader.using('mediawiki.legacy.wikibits', function (){
  importScript(...);
});

---

Rillke 21:43, 23 January 2012 (UTC)

This is an interesting case. Both yes and no.

No:

The legacy wikibits module is loaded in the top queue, which is "blocking state". Meaning other modules won't load until this is loaded (much like "jquery" and "mediawiki" base modules). This is done for legacy reasons so that old scripts using these deprecated functions will continue to work without having to add such a dependency.

Yes:

If you are using this from a newly-written script that isn't old/legacy, and this module is also loaded in the top "blocking" queue (as of writing, gadgets can't put themselves in this queue, this "Yes" answer only applies to MediaWiki core and extensions), then this dependency is required. However that should be a very rare case, since you shouldn't be using legacy code in new code in the first place. When writing new code, for importScript the replacement is essentially modules/gadgets. If you really must load a script raw and singular from a wiki page inline, then use mw.loader.load with the full action=raw url. That also improves portability by not depending on which wiki the code is ran.

So legacy gadgets that aren't migrated don't have to be "fixed" by adding such dependency on "legacy". But if you see a legacy gadget and willing to spend time on them, consider porting them for real so that they don't use any legacy code in the first place (i.e. merge them in a single script page, or keep them separate and use the 'pipe-separated' list syntax listing all page names on MediaWiki:Gadgets-definition so that all required scripts are loaded in the module (instead of lazy-loading unminified and asynchronously from inline code). Krinkle 00:42, 24 January 2012 (UTC)

Tracked in Phabricator
Task T27845

Tracked in Phabricator
Task T29535

When writing new code, for importScript the replacement is essentially modules/gadgets.

For more information, see the bugs on the right side. Helder 20:06, 24 January 2012 (UTC)

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

Turning it on?

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.

---

How do you actually activate ResourceLoader? Particularly with an older pre 1.16 skin?

Furthermore, how do you load individual plug-ins? 86.43.191.217 00:38, 25 March 2013 (UTC)

Skins have little to no documentation. Look at the Vector skin that skips with your MediaWiki version (1.20 I hope?) and use that as leading example.

There is no turning it on, ResourceLoader is everywhere. It is all around us. Even now, in this very room.

A few (but not all) key points in making sure you're not breaking the javascript loading flow:

• Use $this->html( 'headelement' );
• Use $this->printTrail
• Use $out->addModules( .. );
• Don't use <script src="..." ..> Krinkle (talk) 22:03, 25 March 2013 (UTC)

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

(s)maxage

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.

---

Should we remove the smaxage (and maxage?) from the examples, as suggested by de:Wikipedia:Technik/Skin/JS/Obsolet#smaxage=? Helder.wiki 16:53, 26 May 2014 (UTC)

Yes, they seem to have no effect whatsoever; the server always returns zero. — Edokter (talk) — 08:45, 27 May 2014 (UTC)

Done by Krinkle. Helder.wiki 14:03, 18 July 2014 (UTC)

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

Informing communities before the breaking changes

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.

---

Hi, I'm Kenrick from Indonesian Wikipedia and was not happy that you proceed, without communication with us, to require all gadgets to use ResourceLoader per the MediaWiki 1.26 update. Hence, all of our legacy gadgets are unusable until someone reported it today. Although the fix is simple and I've done it in less than 15 minutes, I think it is still a good idea to inform communities before doing a change that may break the legacy gadgets. Thank you. Kenrick95 (talk) 10:50, 7 August 2015 (UTC)

+1. This broke a lot of things, and confused and frustrated a lot of people. Not everyone has the technical understanding to figure out what the problem is and how to fix it - we just see things that aren't working. Nikkimaria (talk) 12:56, 7 August 2015 (UTC)

Same here. It's also really not obvious how to find this page once the tools have stopped working. I've added a note at the top of ResourceLoader to help other people encountering this issue. (see https://www.mediawiki.org/w/index.php?title=ResourceLoader&type=revision&diff=1822030&oldid=1761375 - I can't figure out how to add that link properly here, since neither wikitext or html works!) Mike Peel (talk) 17:39, 8 August 2015 (UTC)

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

Gadget is not loaded on my.wikipedia

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.

---

Hi, I recently installed HotCat Gadget to mywiki via hotlinking Commons version. After setting up, Special:Gadgets shows the error "Gadget is not loaded. Please migrate to ResourceLoader." I already added on gadget definition page as "HotCat[ResourceLoader|rights=edit,purge]|HotCat.js", but it's not working. There is no gadget is installed before this. Please help. Thanks. Ninja✮Strikers ^«☎» 05:37, 19 January 2016 (UTC)

Ah, I changed "HotCat[ResourceLoader|rights=edit,purge]|HotCat.js" to "HotCat[ResourceLoader]|HotCat.js". And got it!! :) Ninja✮Strikers ^«☎» 05:52, 19 January 2016 (UTC)

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

loadedScripts - redundant

What does that exactly mean? What does it duplicate (what to use instead)? MarMi wiki (talk) 22:55, 31 December 2021 (UTC)

As far as I can tell, it has been superseded by mw.loader. Peter Bowman (talk) 23:37, 31 December 2021 (UTC)

So where does mw.loader stores external script url/names loaded by load or getScript? MarMi wiki (talk) 23:53, 31 December 2021 (UTC)

• mw.loader.load('url') -> check $('script')
• mw.loader.getScript() -> this calls $.getScript() internally, which if I'm correct (SO) leaves no trace of the original URL in the HTML Peter Bowman (talk) 00:35, 1 January 2022 (UTC)

Thanks.

I've chosen to test if desired object/function exists to decide if the library is loaded or not. MarMi wiki (talk) 19:11, 4 January 2022 (UTC)

translation of 'upstream'

What does we mean by 'upstream' in "In jQuery 3.0, several deprecated features were removed by upstream." ? Thanks. --Christian 🇫🇷 FR (talk) 11:38, 26 March 2024 (UTC)

@Wladek92 Upstream refers to the makers of the software dependency. jQuery is a JavaScript library, https://jquery.com/ created by the jQuey Team. MediaWiki simply "uses" that. It is not our own code. Krinkle (talk) 15:48, 26 March 2024 (UTC)

Discussion at en:User talk:Enterprisey/script-installer#Confusing history of importScript

You are invited to join the discussion at User talk:Enterprisey/script-installer § Confusing history of importScript. —⁠andrybak (talk) 12:28, 7 June 2024 (UTC)

For jquery.hoverIntent replacement, the live demo needs to be updated

In this section: ResourceLoader/Migration guide (users)#jquery.hoverIntent

Following up to the deprecation of jQuery .hover() (see this change)

The live demo (https://codepen.io/Krinkle/pen/VwGWgqN) that is provided at the end of the section is outdated, and an updated version should be provided, using .on() instead of .hover().

ping @Krinkle Od1n (talk) 14:57, 7 June 2024 (UTC)

Done. Thanks for the ping! Krinkle (talk) 20:46, 7 June 2024 (UTC)

Thank you for updating the live demo. As an added benefit, the code based on on() can very easily be written in vanilla JavaScript, simply by using addEventListener and classList. Od1n (talk) 14:21, 8 June 2024 (UTC)