Extension talk:Gadgets

Previous discussion was archived at Extension talk:Gadgets/Archive on 2012-01-06.

Previous page history was archived for backup purposes at Extension talk:Gadgets/LQT Archive 1 on 2015-07-10.

Hi,

I’ve just noticed that the requiresES6 option is marked as removed since version 1.42. However, it seems that it is not the case. I tried removing it from a gadget’s definition on frwikt (which is on version 1.44 according to its fr:Special:Version page) and it broke the gadget. Moreover, the fr:Special:Gadgets page shows a specific text when the option is specified, hinting that the option might still in fact be supported.

Is this an error on the extension’s page or am I missing something?

Suppose we have an hidden gadget that is – and always has been – hidden:

Foobar [ResourceLoader|hidden] | Foobar.js

If later we add the "default" keyword to it, will it become enabled for all users? Conversely, if later we remove the "default" keyword, will it become disabled for all users?

To put it otherwise, will the gadget be enabled/disabled for all users according to the presence or absence of the "default" keyword? Or is there any possibility that the activation state remains at what it was at a previous time (for instance, at the time the definition was created)?

I guess the activation state will match the presence or absence of the "default" keyword. But I would need to be 100% sure about this, as I considered tweaking a module that brings core functionality on frwiki, and it would rely on this behavior.

(for the sake of completeness, I know users can enable/disable gadgets – probably even the hidden ones – using the API instead of the Preferences page, but let's assume no one did this) (edit: apparently, according to phab:T299071, making such API request on an hidden gadget doesn't change its activation state)

Every time a page is requested from the server, it is checked for this particular account for this particular action which gadgets will be sent for loading.

That means that a change in gadget definitions has full effect rather immediately.

I had a quick look at the code, and phab:T299071 might be of great interest.

1. Hidden gadget are not added to the mw.user.options data: Hooks.php#149.
2. Later, the value is looked for, and because it doesn't exist, "onByDefault" is used as a fallback value: Gadget.php#249.

Therefore, we are sure hidden gadgets will be enabled/disabled depending on whether the "default" keyword is currently in the gadget definition.

Though, T299071 was only purposed as an optimization to reduce data size. I don't know if the loading behavior of hidden gadgets would have been the same without T299071. (edit: according to OP in T299071, hidden gadgets were already following this loading behavior before T299071)

In the mw.user.options a copy of Special:Preferences of registered accounts is transferred to the page JavaScript environment. Actually these are the items where by default or at least by user tic an activated value says that this gadget is to be run.

If you declare a non-hidden gadget to be hidden later, I guess a shadow of the old (last in effect) state might survive in the mw.user.options object of registered accounts.

On page loading, the mw.user.options (which are empty for anonymous users) will set to some kind of true value for all default gadgets, if not opt-out by registered accounts.

There can be arbitrary entries in mw.user.options created to some extent, which were never part of Special:Preferences.

Independent of JavaScript and mw.user.options packages of modules will be provided and sent based upon the current account for this particular action rendered in this particular skin for this particular namespace perhaps matching a certain category.

Anybody happen to know (*cough*@Krinkle*cough*) whether / what comment syntax MediaWiki:Gadgets-definition supports? For things like site-wide styles or gadgets (default|hidden), things meant to be loaded by other gadgets, etc. it'd be very useful to drop a comment in the definition to help other admins out when trying to figure out what something does or why it is the way it is. Not that I've spent waaay too much time cleaning up inherited code here or anything… :)

Hello. <!--HTML comments--> worked for me.

HTML comments are removed before any processing. However, spaces around them aren’t, which has caused issues in the past (phab:T354385), so you should look out for spacing-related issues if you use comments.

Hi. Shouldn't gadget definitions be removed? Shouldn't categories be added?

It works.

Is 'minify' works for ES6 gadget (requiresES6)?

When do you refer to the page "MediaWiki:Gadgets-definition" misunderstandings may arise.

1) Should I use the namespace MediaWiki even if I have declared another one in my LocalSettings.php (eg: $wgMetaNamespace = "Iubar";) ?

2) Is the page Gadgedts-definition valid for any no US/UK locale installation of mediawiki ?

(eg: in Italian the translation of Gadgets is Accessori)

1. Changing $wgMetaNamespace does not affect MediaWiki: namespace, they're separate things

2. Yes. You just use it exactly as you see it (in English) irrespective of the wiki language.

$wgMetaNamespace controls the name of the namespace that’s called Project on mediawiki.org, not the one that’s called MediaWiki. The name of the namespace MediaWiki can be localized on non-English wikis (through software localization, not in LocalSettings.php), but MediaWiki always works as an alias, so you can just type MediaWiki:Gadget-definition in the search on every wiki in the search field, and it’ll find the right page.

Thank you, resolved

I have several gadgets which contain only CSS and type is styles. However, no matter how I sort them in gadgets-definitions, the order they are loaded seems unchanged. Are they loaded in the alphabetical order, or the order they are defined in gadgets-definitions?

I'm not extremely familiar with gadgets, but likely alphabetical order if they're handled in a similar way as other ResourceLoader modules.

It's unclear where the source files implementing gadgets go. The page only discusses defining which are available to users, but doesn't specify where the extension looks for the provided filenames for gadgets.

It should link to this: Gadget kitchen#Deploying or enabling a gadget

@Mcint

The definition syntax is * mygadget [options] | page names. The easiest and recommended way to create or edit the source code pages is through Special:Gadgets, where we automatically render each gadget's metadata in way that you can interact with, to create or edit the source codee page. You can learn more about the syntax and the special page, near the top of the page at Extension:Gadgets#Usage.

Alternatively, if you prefer navigate to a source page yourself, you could prepend "MediaWiki:Gadget-" in front of the specified page name. For examples of this logic, refer to the docs at Extension:Gadgets#Pages.

https://commons.wikimedia.org/wiki/Special:Gadgets

• doesn't have a way to link to sections (Special:Gadgets#blabla),
• doesn't have a table of contents.
• doesn't have a Talk: page.

Last one first: No special page has a talk page in namespace (while it might be connected with flow discussion thread?).

First and second: Well, actually a good idea. Fragment identifiers might be derived from headline text at least, and perhaps the TOC algorithm may be applied to this particular special page, fed by the headline collection.

The definitions page (linked from the lead) is a regular page and does have a talk page.

The anchors should be generated from the raw section IDs (as seen on MediaWiki:Gadgets-definition, e.g. #Navigation instead of #Improved navigation), so that they remain the same across UI languages.

If users are looking at headline Improved navigation in particular language version, they will copy text of headline and use it for linking.

• No regular reader has access to the internal system message ID.

Therefore both id= need to be hidden in generated HTML:

• Visible headline text in particular language, available within that uselang= only.
• System message ID for programmers; rather sophisticated.

On regular pages there is currently

• <h2> without any id= now
• <span> with headline text in page language and id= generated from that localized text; also when generating TOC
• <span> with toolbox in user language

The first one might address the language independent fragment, the second one such visible text, and third one is not really expected on a special page.

• If both fragments are identical, one is to be omitted to ensure HTML document validity.

Someone should start a feature request at Phabricator.

I found that ja:MediaWiki:Gadget-dark-mode.css, which is @import en:MediaWiki:Gadget-dark-mode.css, does not work well. The reason seems that must come before all other types of rules but it's loaded on the bottom of load.php.

.mw-parser-output a[href$=".pdf"].external,
.mw-parser-output a[href*=".pdf?"].external,
.mw-parser-output a[href*=".pdf#"].external,
.mw-parser-output a[href$=".PDF"].external,
.mw-parser-output a[href*=".PDF?"].external,
.mw-parser-output a[href*=".PDF#"].external {
 background:url(//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif) no-repeat right;
 padding-right:18px
}
span.PDFlink a {
 background:url(//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif) center right no-repeat !important;
 padding-right:17px !important
}
.allpagesredirect a:link,
.allpagesredirect a:visited,
.redirect-in-category a:link,
.redirect-in-category a:visited,
.watchlistredir a:link,
.watchlistredir a:visited {
 color:#595959
}
.client-js > body.skin-vector #p-personal li {
 font-size:0.75em
}
.client-js > body.skin-monobook #p-personal li {
 font-size:1em
}
.client-js > body.skin-vector #p-personal ul {
 margin-right:5.0625em
}
.client-js > body.skin-monobook #p-personal ul {
 margin-right:7.6em
}
@import url(https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-dark-mode.css&action=raw&ctype=text/css);

How can I fix this? Do you have any tips to use @important on the Gadgets?

Hi. Indeed, the CSS format does not permit use of @import anywhere other than at the start of a stylesheet. However, the guruantees we provide for batching and ordering stylesheet modules requires exactly that (in most cases) we place it somewhere later in the response.

In ResourceLoader we have a legacy exception for the "user" (personal user css) and "site" (site-wide Common.css) modules which historically are unable to register their subfiles as native. The exception is that when we encounter a later chunk, we split it out into a new request and/or flush the chunk as its own <style> element.

For all other modules (MW core, extensions, and gadgets) it is expected that code is loaded natively for optimium performance as we do not want the visual rendering of articles to be delayed by late-discovered additional requests, especially requests to other domains.

The type option for gadgets (docs) can switch between pure "styles" and "general". The main benefit of "styles" is that it loads immediately and before the page is visually rendered. However, this immediate-ness is contradicted when importing files from other wiki. The browser does not know about these files until after all the styles have arrived. Delaying rendering at this point is slow.

Your options are:

1. Make it a locally cached and optimised gadget, by copying the page content as well. This creates fast page views and no delays of dark mode.
2. Alternatively, you can set type=general. I tried this in jawiki rev 90881097 and confirmed that this "works" in so far that it makes the page render exactly as fast as if dark mode was not there, but then dark mode arrives at the same time as it would if we were to delay rendering for cross-domain styles import. Despite being faster, this way feels slower because we first see the fast page rendering and only then the dark mode.

There are ways to support @import with workarounds in our software that create complicated ways of loading stylesheets, that are difficult to debug and understand. I have choses in the past not to support this, and instead invest the cost in making everything else faster and simpler. The first option would be my recommendation in today's possibilities.

There is a third option, which is to develop the code as an extension and seek deployment (or in the future, "global gadgets", phab:T22153).

Thank you for your advice. I understand current situation. I followed your suggestion#1 (copying) for dark-mode.css.