Page MenuHomePhabricator

97: Port GlobalWatchlist.js into a gadget [spike]
Closed, DeclinedPublicSpike

Description

Converting this script into a gadget might be a good idea since it has many users. This will help us to provide better performance, since ResourceLoader modules (including gadgets) are automatically minified along with various other features. It will load the code that is needed and saving data. Thoughts?

Event Timeline

Restricted Application assigned this task to DannyS712. · View Herald TranscriptJan 23 2020, 8:10 AM
Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald Transcript
Restricted Application added a subscriber: DannyS712. · View Herald Transcript
Restricted Application added a project: User-DannyS712. · View Herald TranscriptJan 23 2020, 8:12 AM
Masumrezarock100 added a comment.EditedJan 23 2020, 8:16 AM

@DannyS712 if you agree, I believe we can port this gadget to mediawiki.org (best fit IMO) for now since you have interface adminship there. Keeping this gadget to meta is also a good idea but you don't have interface adminstrator rights there and we will have to wait on a interface admin to update the script if a serious bug pops up.

@DannyS712 if you agree, I believe we can port this gadget to mediawiki.org (best fit IMO) for now since you have interface adminship there. Keeping this gadget to meta is also a good idea but you don't have interface adminstrator rights there and we will have to wait on a interface admin to update the script if a serious bug pops up.

Except that the code needs to be executed on all wikis, not just when the user is on mediawiki...
T22153: Implement global gadgets (WMF-wide) would do that, but that appears to be waiting for T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites

I'm not sure what the hard part is: MediaWiki-extensions-GlobalPreferences and/or GlobalCssJs should make it pretty easy

Masumrezarock100 added a comment.EditedJan 23 2020, 8:33 AM

@DannyS712 I am aware that global gadgets isn't a thing at the moment. But we can just import the gadget module from Mediawiki.org. For example, https://en.wikipedia.org/w/load.php?modules=ext.gadget.dropdown-menus. The code of ext.gadget.dropdown-menus is extensively and automatically minified as you can see. Another example would be the RTRC gadget. It resides on mediawiki.org but can be loaded globally via global.js.

(mw.loader.getState('ext.gadget.rtrc') ? mw.loader.load('ext.gadget.rtrc') : mw.loader.load('https://www.mediawiki.org/w/load.php?modules=ext.gadget.rtrc&lang=en'));

After porting it to mediawiki.org as a gadget, your user subpage of the script can just mirror the gadget from mediawiki.

In that case, it would probably make the most sense to host on meta wiki, since that is the "central" wiki

Masumrezarock100 added a comment.EditedJan 23 2020, 8:58 AM

In that case, it would probably make the most sense to host on meta wiki, since that is the "central" wiki

True, but I am concerned about the comments I made in T243489#5825762. You'll need to apply there for interface adminship if you wish to keep it updated as soon as possible.

In that case, it would probably make the most sense to host on meta wiki, since that is the "central" wiki

True, but I am concerned about the comments I made in T243489#5825762. You'll need to apply there for interface adminship if you wish to keep it updated as soon as possible.

True... let me think about it. The eventual goal is an extension :)

Masumrezarock100 added a comment.EditedJan 23 2020, 2:28 PM

True... let me think about it. The eventual goal is an extension :)

Yes, and making this an onwiki gadget is just a small but big step on that path. I think many users who wants a global watchlist do not know about your script. Making it a gadget will let users know about this (the Gadgets section in the preferences is a highly visited page).

Making it a gadget doesn't mean that it will always be loaded - it'll still require an import in the global.js

Making it a gadget doesn't mean that it will always be loaded - it'll still require an import in the global.js

True, how about making it a hidden gadget, like how gadget dependencies are added? This will remove keep the gadget hidden from the preferences page but we it will still function if we import the module via global.js until T22153: Implement global gadgets (WMF-wide) is implemented. This way people will not have to install it twice and they can still enjoy ResourceLoader features. Which is why I said making it a gadget (hidden or normal) on any project is enough. My original proposal was this. One benefit is that we can ship a lightweight version of the script while keeping the eslint, jshint and other documentation comments inside the script.

Masumrezarock100 added a comment.EditedJan 23 2020, 5:22 PM

If we make it a hidden gadget, we can do the following:

  • Make necessary changes to the script/would-be gadget. Split the script into multiple gadget modules if needed. Implement them as hidden gadgets.
  • Then we can just deprecate the importing via your userpage JS method and redirect your userpage to the new gadget resourceloader module.

Pros:

  • We can ship a lightweight version of the script, better performance.
  • Update the script documentation on enwiki to load the module instead of the userpage. We will not remove/hard-deprecate the previous import method, to avoid breaking its uses. We will redirect your userspace to the new resource loader module. We can notify users about this change. It is their choice if they choose to migrate the new import method.
  • Importing via userpage will continue to work as I said above. Users will not notice anything significant, just the script's loading will be faster.

Cons

Any?

If we keep the gadget visible. Users may get confused because of two installing methods.

DannyS712 renamed this task from SPIKE: Port GlobalWatchlist.js into a gadget to 97: Port GlobalWatchlist.js into a gadget [spike].Jan 28 2020, 10:43 PM

Actually, tried to do this and failed. Did not investigate what's happening, but my wild guess is that the script is too large to be a gadget. Do not know.

Actually, tried to do this and failed. Did not investigate what's happening, but my wild guess is that the script is too large to be a gadget. Do not know.

The script can always be split into multiple parts. There are many larger scripts, for example AQD and VFC on Commons. They work fine as a gadget. Well just copy-pasting the code isn't enough, the script needs to be modified so it can work as a gadget. I haven't looked at the full code yet. Maybe the script has some JS code that isn't supported by the ResourceLoader (T75714 is one of them). I wonder what exact problem you were facing.

I wonder what exact problem you were facing.

The console shows a message "unclosed parentheses". Tried several variants, the message is the same, the location of opening "(" is different, but accordand ")" is always very far in the code. So my first thought was that not all the lines are accepted.

Krinkle added a subscriber: Krinkle.EditedFeb 12 2020, 10:13 PM

Here is an example of a "global" gadget within today's possiblities. My RTRC gadget is maintained at https://github.com/Krinkle/mw-gadget-rtrc. It is defined as gadget at https://www.mediawiki.org/wiki/MediaWiki:Gadgets-definition (rtrc.js and rtrc.css).

To use it from other wikis, I document the following snippet:

(mw.loader.getState('ext.gadget.rtrc') ? mw.loader.load('ext.gadget.rtrc') : mw.loader.load('https://www.mediawiki.org/w/load.php?modules=ext.gadget.rtrc&lang=' + mw.config.get('wgUserLanguage', 'en')));

What this does:

  • Check if ext.gadget.rtrc is defined on the current wiki. This is true for example on mediawiki.org.
  • If yes, then load it as a normal module. Then mw.loader takes care of making the url, the version, language code, caching etc.
  • If no, then load it from mediawiki.org with lang= set to the interface language of the current user. This means that for RTL languages, the CSS will be automatically flipped by ResourceLoader.

This line loads all CSS/JavaScript files from the gadget via one url. Combined by ResourceLoader.

Here is an example of a "global" gadget within today's possiblities. My RTRC gadget is maintained at https://github.com/Krinkle/mw-gadget-rtrc. It is defined as gadget at https://www.mediawiki.org/wiki/MediaWiki:Gadgets-definition (rtrc.js and rtrc.css).

To use it from other wikis, I document the following snippet:

(mw.loader.getState('ext.gadget.rtrc') ? mw.loader.load('ext.gadget.rtrc') : mw.loader.load('https://www.mediawiki.org/w/load.php?modules=ext.gadget.rtrc&lang=' + mw.config.get('wgUserLanguage', 'en')));

What this does:

  • Check if ext.gadget.rtrc is defined on the current wiki. This is true for example on mediawiki.org.
  • If yes, then load it as a normal module. Then mw.loader takes care of making the url, the version, language code, caching etc.
  • If no, then load it from mediawiki.org with lang= set to the interface language of the current user. This means that for RTL languages, the CSS will be automatically flipped by ResourceLoader.

This line loads all CSS/JavaScript files from the gadget via one url. Combined by ResourceLoader.

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

Unlike RTRC, GlobalWatchlist has truly global functionalities. I see no need to define GW on other wikis. Just in a central wiki is enough. Since new users may get confused because of different install methods.

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

No, it only needs to be defined as a gadget once, on one wiki (for RTRC, I choose mediawiki.org). ResourceLoader takes are of the rest.

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

No, it only needs to be defined as a gadget once, on one wiki (for RTRC, I choose mediawiki.org). ResourceLoader takes are of the rest.

Okay. Given that the global functionality is on meta, and that is where I have been updating it, it makes sense to define it there (imo). Thanks for the info

Nice. Metawiki or Mediawiki either one is fine to me. But my concerns in T243489#5825762 are valid. May I ask when you are planning to start a discussion there, and request for interface adminship?

DannyS712 changed the task status from Open to Stalled.Feb 23 2020, 1:14 AM

Nice. Metawiki or Mediawiki either one is fine to me. But my concerns in T243489#5825762 are valid. May I ask when you are planning to start a discussion there, and request for interface adminship?

I'm in the middle of an RfA on wikidata, so I'm not planning to open a request anytime soon. Also, if the grant is approved this will all be moot, since I'll convert it to an extension instead. Lets wait until the grant results

This comment was removed by DannyS712.
Krinkle removed a subscriber: Krinkle.May 7 2020, 5:29 PM
DannyS712 closed this task as Declined.Jun 11 2020, 5:24 AM

[batch] My grant to create a global watchlist extension has been approved, and I will no longer be working on the user script. Please file any new bug reports and feature requests with the extension rather than here.