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.
Extension talk:Gadgets
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 anyid=now<span>with headline text in page language andid=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:
- 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.
- 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.
I installed this extension but it doesn't work, where could the problem be?
You're going to have to provide more detail: did you follow the usage instructions? What exact steps did you take? Are you seeing any error messages?
wfLoadExtension( 'Gadgets' ); in LocalSettings.php
I put the file in the extensions folder, but the tools are not displayed.
I don't get any error.
I also installed other plugins, I know how to install plugins.
My site https://wikidm.org/
Okay, so this extension does not come with any gadgets actually preinstalled; you have to install them all yourself. Read through the usage instructions that I linked in my previous comment for a basic explanation of how to use the extension.
Thank you very much for the advice, I will read again.
Since I just found out about it myself, Gadget kitchen looks like a very good resource as well.
Thank you very much for your persistence and guidance
Hi, I recently converted a gadget on frwikt to ES6 syntax but despite specifying the 'requiresES6' option in the Gadgets-definition page, I get this error: "JavaScript parse error (scripts need to be valid ECMAScript 5): Parse error: Missing ; before statement in file 'MediaWiki:Gadget-CreerNouveauMot.js' on line 55". The thing is, it works on at least another one. What am I doing wrong? Thanks for your help.
Here are some links:
- Gadgets definition: fr:wikt:MediaWiki:Gadgets-definition#Création
- Gadget that does not work: fr:wikt:MediaWiki:Gadget-CreerNouveauMot.js
- Gadget that does work: fr:wikt:MediaWiki:Gadget-Barre de luxe.js
So, new development, it seems that I get this error only when the "default" option is active as well… Are there any compatibility issues between these two options that I am not aware of? I looked at the documentation but found nothing relating to this topic.
Yes, you can't enable an ES6-only gadget by default as by default implies all users/skins/browsers, whereas by definition it would fail in ES5 browers where we do load other gadgets and stylesheets. This leads to compatibility issues, dependency problems, and code complexity that developers likely wouldn't test well given it doesn't affect their own browsers. Such blind spots create inverse incentives, where the "easy" and default behaviour is to create experiences that aren't accessible through no fault of your own.
The requiresES6 feature is a temporary option to allow experimental opt-in gadgets to start using this until we're ready to drop ES5 support for Grade A. See also Compatibility and T178356.
Makes sense, thanks for your answer :) Unless I’ve missed it, I think it should be specified explicitely in the extension’s documentation so anyone can know before finding out too late.
Is it legal to add extra wikitext like categorization and description text after the title in Mediawiki:Gadget-section-X? Something like this
Title
<p style="font-weight: normal; font-size: initial;">
Section description
</p>
[[Category:Section headings]]seems to work, but can it cause problems later?
@Hunsvotti I would recommend against it. It is a common pattern within Wikipedia communities to use the talk page to categorize interface pages like these. That way the interface script, or interface text remains clean and pure from these organisational types of metadata.
As it stands today, it appears this indeed has no negative side-effects, but it seems like the kind of thing we might change to accomodate something we need in the future. Best to avoid it, I think!
Thanks! Categorizing the talk page didn't even occur to me.
Hi, I'm wondering if it's possible to hide a section of Gadgets-definition on Special:Preferences for users without a certain user right or those who aren't in a particular user group. I'm thinking about adding a section named 'management-gadgets' or something similar on my local wiki and put gadgets for sysops into it, but this will probably result in showing an empty section for non-sysops, am I right here? Any help would be appreciated.
You can restrict individual gadgets only. However, the user interface automatically takes care to hide empty sections.
This works both if the section is empty in the definition page, as well as if the section contains only gadgets that are hidden for the current user.
For example:
==foo== *foo1[hidden|ResourceLoader]|foo1.js *foo2[ResourceLoader]|foo2.js ==bar== ==baz== *baz3[ResourceLoader|hidden]|baz3.js
This show only "foo" section in the preferences, and with one gadget (foo2).
Image captured at https://phabricator.wikimedia.org/F35327419
I just tried to use the Gadget 2.0 design and it is horrible. Description is stored in the Mediawiki namespace. The definition file is stored in the Gadget_definition namespace. The CSS and JS code is stored in the Gadget namespace. Did anybody ever try to actually use this system before implementing it? Why not just leave everything the way it is, but just store all the files in the Gadget namespace, so you have "Gadget:Mygadget Gadget:mygadget.css Gadget:mygadget.js if you need a second file Gadget-mygadget-morejs.js . Inside the Gadget:mygadget, just have a line that says "title" and "description". Then when a person is trying to either copy from an existing Mediawiki or creating their own, they can easily see if a file is missing or existing. Or just copy the templates system of just having mygadget/def or mygadget/json
I wanted to load a gadget from on Meta Wiki.
However, when I using mw.loader.load( "https://zh.wikipedia.org/w/load.php?modules=ext.gadget.shortURL" ); to load, it throw a error:
ReferenceError: wgULS is not defined
at load.php?modules=ext.gadget.shortURL:1:123
at load.php?modules=ext.gadget.shortURL:1:741
at runScript (load.php?debug=2&modules=startup&only=scripts&raw=1:1348:7)
at execute (load.php?debug=2&modules=startup&only=scripts&raw=1:1474:4)
at doPropagation (load.php?debug=2&modules=startup&only=scripts&raw=1:864:6)
wgULS is defined at ext.gadget.site-lib (
zh:MediaWiki:Gadget-site-lib.js
).
So, could I get a gadget's dependencies from api or load.php to automaticly load it before I try to load any gadget, like ext.gadget.shortURL on zhwiki?
It is relying on a function wgULS() which is not specified within this script.
On Meta: they might have defined it on meta:MediaWiki:common.js but they did not now.
ULS does mean Universal Language Selector.
meta:Special:Preferences#mw-prefsection-gadgets does not mention a shortURL gadget. It seems to be unmaintained, if ever alive on meta:.
I do not see where you got the source from.
The source is zhwiki, aka Chinese Wikipedia (site-lib: zh:MediaWiki:Gadget-site-lib.js zh:Special:Gadgets/export/site-lib, shortURL: zh:MediaWiki:Gadget-shortURL.js zh:Special:Gadgets/export/shortURL), not in meta.
so if I tried to load "shortURL gadget" in "zhwiki", it throw error because wgULS isn't defined in meta wiki's common.js or some gadget defined in meta.
In my memories ES6 was not supported due to the limit of ResourceLoader (it was quite a few versions ago), but now ResourceLoader does support ES6. I was told that you can use mw.loader.load but this way there would be a lot of scripts loaded separately, making the packaging meaningless. Seems like there is a "package" option available (unfortunately only in 1.38 and later) and I'm kinda interested.
I believe ES6 support is still blocked by phab:T75714. Besides, per phab:T75714#7365697:
You can use mw.loader.load to load non-gadget non-es5 user scripts (from a URL). You just can't use >es5 in ResourceLoader JS (including user and MediaWiki common.js and skin.js files and gadgets).
As I said, this way there would be a lot of scripts loaded separately. Anyway, thanks for your explanation!
Hello,
I need help. I have created a MediaWiki the extension Gadgets is installed and the steps for ImageAnnotator actually also all done, but unfortunately it does not work at all. I need a simple function from ImageAnnotator it only needs to annotate a single image. If someone would take a look at this or help me, I would be very grateful.