Talk:ResourceLoader/Migration guide (users)

Jump to navigation Jump to search

About this board

Informing communities before the breaking changes

3
Kenrick95 (talkcontribs)

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.

Nikkimaria (talkcontribs)

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

Mike Peel (talkcontribs)

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

3
Rillke (talkcontribs)

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

Krinkle (talkcontribs)

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

He7d3r (talkcontribs)
When writing new code, for importScript the replacement is essentially modules/gadgets.

For more information, see the bugs on the right side.

86.43.191.217 (talkcontribs)

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

Furthermore, how do you load individual plug-ins?

Krinkle (talkcontribs)

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="..." ..>
He7d3r (talkcontribs)
Krinkle (talkcontribs)

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

He7d3r (talkcontribs)

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

Krinkle (talkcontribs)

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

Compare:

He7d3r (talkcontribs)

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.

Krinkle (talkcontribs)

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.

He7d3r (talkcontribs)
Edokter (talkcontribs)

Yes, they seem to have no effect whatsoever; the server always returns zero.

Gadget is not loaded on my.wikipedia

2
Ninjastrikers (talkcontribs)

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.

Ninjastrikers (talkcontribs)

Ah, I changed "HotCat[ResourceLoader|rights=edit,purge]|HotCat.js" to "HotCat[ResourceLoader]|HotCat.js". And got it!! :)

There are no older topics