Now that 1) [[ https://github.com/wikimedia/mediawiki/blob/master/resources/src/startup/startup.js#L40 | ES6 is the Grade A JavaScript requirement for MediaWiki ]] and 2) the validator now supports ES6 (T75714), this means we no longer need the "requiresES6" flag for the gadgets extension, correct?
If these assumptions are correct, then we can start simplifying the codebase and doing other cleanup related to this:
* [ ] evaluate and remove "requiresES6" mentions in code ([[ https://codesearch.wmcloud.org/deployed/?q=requiresES6&files=&excludeFiles=&repos= | codesearch ]]), except for maybe one spot where we make sure "requiresES6" doesn't throw some kind of definition file validation error, for backwards compatibility
* [ ] remove "requiresES6" from MediaWiki:Gadgets-definition files ([[ https://global-search.toolforge.org/?q=requiresES6®ex=1&namespaces=8&title=Gadgets-definition | global search ]])
* [ ] update documentation (such as crossing out requiresES6 at [[ https://www.mediawiki.org/wiki/Extension:Gadgets#Options | mw:Extension:Gadgets#Options ]])
**Feature summary** (what you would like to be able to do and where):
MediaWiki:Gadgets-definition should support splitting gadget definitions over multiple lines.
This could perhaps be done by treating any line starting with whitespace, `|`, `[` or `]` as part of the previous line.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
MediaWiki:Gadgets-definition now supports a lot of options for gadgets. These are useful, but using them makes the definitions hard to read and edit, because the entire definition has to be on the same line.
If the gadget maintainers don't add whitespace to the definitions, it can also cause the page to scroll horizontally (e.g. https://commons.wikimedia.org/wiki/MediaWiki:Gadgets-definition scrolls horizontally for me unless the window is at least 1600px wide).
Storing the definitions using a different format would be the best option, but that doesn't seem like it's going to happen soon.
**Benefits** (why should this be implemented?):
It would make gadget definitions easier to read and edit.
For example, one of the longest definitions on the Commons page is
```
* Twinkle[ResourceLoader|dependencies=ext.gadget.morebits,ext.gadget.select2,mediawiki.api,mediawiki.language|rights=autoconfirmed|type=general|peers=Twinkle-pagestyles|requiresES6]|Twinkle.js|Twinkle.css|twinklespeedy.js|twinkleimage.js|twinklediff.js|twinkleunlink.js|twinklefluff.js|twinklebatchdelete.js|twinklebatchprotect.js|twinklebatchundelete.js|twinkleconfig.js
```
If splitting a definition over multiple lines were supported, this could perhaps be written as
```
* Twinkle
[
ResourceLoader
| dependencies = ext.gadget.morebits, ext.gadget.select2, mediawiki.api, mediawiki.language
| rights = autoconfirmed
| type = general
| peers = Twinkle-pagestyles
| requiresES6
]
| Twinkle.js
| Twinkle.css
| twinklespeedy.js
| twinkleimage.js
| twinklediff.js
| twinkleunlink.js
| twinklefluff.js
| twinklebatchdelete.js
| twinklebatchprotect.js
| twinklebatchundelete.js
| twinkleconfig.js
```
Written like that, I think it's much easier to see which resource loader options are being used, which pages are included, whether they're CSS, JS or JSON, etc.
**Feature summary** (what you would like to be able to do and where):
Gadget definitions should support a list of interface messages to load when the gadget is loaded, similar to "messages" for resource modules in extension.json files ([[https://codesearch.wmcloud.org/deployed/?q=%22messages%22&files=extension.json|code search]])
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Gadgets, particularly those on multilingual wikis or designed to be used on multiple wikis, should have translated interfaces. Interface messages can be used in gadgets using `mw.msg()`, but this only works if the messages are loaded first.
Most translatable gadgets store the translations in the script, which makes it difficult for translators to easily find or edit the messages. Gadgets which implement translations in this way also often don't implement fallback handling.
Adding messages to a repository such as WikimediaMessages would make them translatable on Translatewiki, but that makes it harder to use the messages. Interface messages often aren't available to the gadget by default and while there is a way to load missing messages using the API, it does not seem to be used much and creates extra network requests.
**Benefits** (why should this be implemented?):
It would simplify the gadget code, by not requiring it to manually load messages before running the rest of the script. This would make it easier to write/maintain translatable gadgets.
Gadgets would not need a dependency on mediawiki.api and extra network requests to load interface messages.
Using interface messages would provide automatic fallback handling.
**Feature summary** (what you would like to be able to do and where):
The special page https://en.m.wikipedia.org/wiki/Special:GadgetUsage should show the bytes associated with each gadget and inform interface admins what this means for site performance. Right now, gadgets on certain projects contribute to poor site performance and poor SEO which hurts the movement. In most cases this seems to be due to a lack of understanding of the impact of "default" gadgets on these key metrics (see T340705 for examples)
To provide better guidance and tooling for our gadget developers to make the right decisions it would be useful if the GadgetUsage tool could be used to help make these decisions.
**Requirements**
[] Show a note which documents the amount of kb for CSS and JS for a page view in the default skin
[] Update the table to show the size of each module so that admins can sort modules by largest.
**Design**
{F42653881,size=full}
** Implementation notes **
* For Calculating the size of modules you can use this function:
```
/**
* Calculates the size of a module
*
* @param string $moduleName
* @param string $skinName
*
* @return float|int
* @throws \Wikimedia\RequestTimeout\TimeoutException
* @throws MediaWiki\Config\ConfigException
*/
protected function getContentTransferSize( $moduleName, $skinName ) {
// Calculate Size
$resourceLoader = $this->getServiceContainer()->getResourceLoader();
$resourceLoader->setDependencyStore( new KeyValueDependencyStore( new HashBagOStuff() ) );
$request = new FauxRequest(
[
'lang' => 'en',
'modules' => $moduleName,
'skin' => $skinName,
]
);
$context = new Context( $resourceLoader, $request );
$module = $resourceLoader->getModule( $moduleName );
$contentContext = new \MediaWiki\ResourceLoader\DerivativeContext( $context );
$contentContext->setOnly(
$module->getType() === Module::LOAD_STYLES
? Module::TYPE_STYLES
: Module::TYPE_COMBINED
);
// Create a module response for the given module and calculate the size
$content = $resourceLoader->makeModuleResponse( $contentContext, [ $moduleName => $module ] );
$contentTransferSize = strlen( gzencode( $content, 9 ) );
// Adjustments for core modules [T343407]
$contentTransferSize -= 17;
return $contentTransferSize;
}
```
* For rendering the notice you can use https://doc.wikimedia.org/codex/latest/components/demos/message.html#css-only-version
* "These guidelines" should be linkable to a wikipage on the subject that is configurable by a MediaWiki message. By default it can link to https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Frontend_performance_practices
**Benefits** (why should this be implemented?):
* Poor performance hurts SEO
* Poor performance provide challenges for slower connections to access our content
Support use of ES8 code in gadgets. This involves confirming that Grade A browsers support ES8 syntax, switching the Peast validator to ES8 mode, and changes in the JS minifier.
**Feature summary** (what you would like to be able to do and where):
Images/videos of gadgets should be shown next to gadgets in the [[ https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-gadgets | Gadgets section ]] of your preferences.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Users should be able to see what the gadget actually does instead of a text description. For the list of userscripts at wikidata we provide images next to most of our userscripts: https://www.wikidata.org/wiki/Wikidata:Tools/Enhance_user_interface
**Benefits** (why should this be implemented?):
Users would be more likely to add userscripts as official gadgets as they would get as much visibility in their offered functionality as our current userscript list provides.
When editing high-usage templates you get a warning:
{F41559673}
For gadget source code pages it would be useful to show usage stats so we can gauge how critical the code is before applying fixes.
Special:Gadgets displays message atop gadgets list saying that the gadgets are derived from their definitions on MediaWiki:Gadgets-definition.
This is however incorrect if Gadget definition namespace is in use.
**Feature summary** (what you would like to be able to do and where):
Add something like `isLoggedIn` to https://www.mediawiki.org/wiki/Extension:Gadgets#Options
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
**Benefits** (why should this be implemented?):
* avoid hacks such as https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&curid=14548426&diff=1181939245&oldid=1181893240
* less prone to breakage than a hack (which recently broke)
* syntax will be more readable
**Feature summary** (what you would like to be able to do and where):
Some gadgets run on watchlist and history pages. It should be possible to load those gadgets on only the page that's needed.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
There are gadgets on English Wikipedia that apply only to the history and watchlist pages. Since there is no way to limit gadgets just to these pages these gadgets are loaded across all pages for anonymous users without duplicating the gadget and using namespaces=-1 and actions=history options.
**Benefits** (why should this be implemented?):
* unused and significant chunks of CSS won't be loaded on all pages.
See also T345960 and T340705.
If statistics and some guidance (possibly averages?) are provided this could help communities and administrators to make informed decisions.
Here's a rough idea on how this might be provided. Feel free to add to/improve this task description but please keep true to the spirit of it: to inform, not to sanction.
# Create a loop with a list of all project (sub)domains e.g. "en.wikipedia.org", "es.wikipedia.org", "www.wikidata.org", etc
# Read MediaWiki:Gadgets-definition, for example https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Gadgets-definition?action=raw
# Create two lists of gadget names: those that are default+not action specific+require no rights and a superset consisting of all gadget names.
# Make a request that loads all default gadgets, e.g. https://commons.wikimedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.gadget.betaCommons%2CUploadWizard%2CImageAnnotator%2CuploadWizardMobile%2CAnonLoader%2Cswitcher&skin=vector-2022
# Check length of response
# Check gzipped length of response
# Create a loop to load every gadget individually like this, check length+gzipped length
# Turn this information into two pie charts, one for all gadgets and one for the default gadgets, using HTML and possibly also a wikicode version (https://www.mediawiki.org/wiki/Extension:Cargo can create pie charts but doesn't seem to be installed on Wikimedia)
# Have a bot/script upload/post this on ToolForge or somewhere on-wiki.
Currently anyone with the correct rights can edit [[MediaWiki:Gadgets-definition]] to turn gadgets on for anonymous users. Left unchecked this has led to some performance problems and potential SEO (related to slow loading) on many of our smaller sites leading to T340705.
We should be doing more to guide site admins on when they are introducing performance/SEO problems to the site.
In MediaWiki we've been investing a lot of effort in limiting the amount of CSS and JS we ship to our end users, but any improvements here are meaningless if the same is not happening within gadgets.
I think we should enforce a performance budget for all gadgets that have been marked as "default".
To do this we need
[] Some way to calculate the amount of Kb of default gadgets are shipped to anonymous users
[] A number that represents an upper bound for this code.
# Future usages
Once we have such a number this could then be checked and either:
* Printed on the MEdiaWiki:Gadget-definitions page itself as a warning box (With guidelines of what is a high amount of code and small)
* Used to send Echo notifications to site admins when
* Disable all (or some of the) default gadgets when the "budget" has been surpassed.
* If it's possible to check this quickly on edit, we might refuse to allow edits to the page that introduce gadgets that exceed performance budget.
In [[special:GadgetUsage]] the default gadgets does not have Statistics only "default" word, but there are some users deactivate these gadgets I want to know how many users deactivated the gadget by something like (default - 10) means there 10 users deactivate this gadget. It is useful to me as Interface admin to decide what to stay a default and what to be optional.
When gadgets break or are going to break it is important for Wikimedia developers to know who to contact. Right now there is no easy way to check who maintains a gadget - many gadgets are built and then the maintainers go away.
As a starting point I think anything defined in https://en.wikipedia.org/wiki/MediaWiki:Gadgets-definition should require a maintainers field which includes at least one valid username.
Any "default" gadget (code ran for anonymous users) with no maintainer shouldn't be permitted - we shouldn't be running code for everyone where there is no maintainer. That would be irresponsible.
Knowing gadgets have maintainers would be a reassuring requirement going forward as we evolve our front end code.
e.g.
```
* edittop[ResourceLoader|dependencies=user.options,mediawiki.util|type=general|maintainer=jdlrobson]|edittop.js|edittop.css
```
Many gadgets are loaded in environments they are not ever used. For example:
* A gadget may want to be used in devices where a mouse is available (and thus it is possible to hover over references).
* Some gadgets require a certain screen size
* Some gadgets rely on a certain editor being available e.g. mobile editor
* Some gadgets add functionality that is not needed on the mobile Minerva skin. For example section collapsing is added on Minerva but only on mobile site. The MultimediaViewer is different on mobile and desktop (tracked in T65504) and Minerva has native support for tooltips so the gadget Reference Tooltips is not needed there.
* MobileFrontend removes content from the article which means gadgets don't work as expected e.g. removal of navboxes breaks the navboxNavigation gadget. (T124168)
Originally suggested by @tgr in T127268#8974464 we should provide "skipFunctions" for gadgets that allow gadget code to not load in certain circumstance.
Initially skipFunctions could be defined inside the Gadget extension and Gadget definitions could use them by reference
e.g. This might look something like this where requires=!touch-device adds a skip function relating to touch device support.
```
var isTouchDevice = 'ontouchstart' in document.documentElement;
var desktopResolution = window.innerWidth >= 1000;
```
```
* ReferenceTooltips[ResourceLoader|default|requires=!touch-device,desktop-resolution|skins=vector,vector-2022,monobook,timeless,modern,cologneblue|type=general|dependencies=mediawiki.cookie,jquery.client]|ReferenceTooltips.js|ReferenceTooltips.css
```
Some gadgets don't work in one specific skin (often because they aren't designed for mobile/Minerva), yet we have to list all the deployed skins //except// that one to implement this, e.g.
```
ReferenceTooltips[ResourceLoader|default|skins=vector,vector-2022,monobook,timeless,modern,cologneblue|type=general|dependencies=mediawiki.cookie,jquery.client]|ReferenceTooltips.js|ReferenceTooltips.css
```
It would be neater if we could just write
```
...|skins=!minerva|...
```
or
```
...|disableskins=minerva|...
```
==== Error ====
* service.version: 1.41.0-wmf.15
* trace.id: 36777ef9-301b-4b37-86f2-940b1bcca706
* [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2023-06-26T18:38:27.852Z',to:'2023-06-27T18:40:10.254Z'))&_a=(query:(query_string:(query:'reqId:%2236777ef9-301b-4b37-86f2-940b1bcca706%22'))) | Find trace.id in Logstash ]]
```name=labels.normalized_message,lines=10
[{reqId}] {exception_url} TypeError: Argument 1 passed to MediaWiki\Extension\Gadgets\Gadget::__construct() must be of the type array, object given, called in /srv/mediawiki/php-1.41.0-wmf.15/extensions/Gadgets/includes/MediaWikiGadgetsDefinitionRepo.php
```
```name=error.stack_trace,lines=10
from /srv/mediawiki/php-1.41.0-wmf.15/extensions/Gadgets/includes/Gadget.php(75)
#0 /srv/mediawiki/php-1.41.0-wmf.15/extensions/Gadgets/includes/MediaWikiGadgetsDefinitionRepo.php(38): MediaWiki\Extension\Gadgets\Gadget->__construct(MediaWiki\Extension\Gadgets\Gadget)
#1 /srv/mediawiki/php-1.41.0-wmf.15/extensions/Gadgets/includes/GadgetRepo.php(72): MediaWiki\Extension\Gadgets\MediaWikiGadgetsDefinitionRepo->getGadget(string)
#2 /srv/mediawiki/php-1.41.0-wmf.15/extensions/Gadgets/includes/Hooks.php(130): MediaWiki\Extension\Gadgets\GadgetRepo->getStructuredList()
#3 /srv/mediawiki/php-1.41.0-wmf.15/includes/HookContainer/HookContainer.php(153): MediaWiki\Extension\Gadgets\Hooks->onUserGetDefaultOptions(array)
#4 /srv/mediawiki/php-1.41.0-wmf.15/includes/HookContainer/HookRunner.php(4212): MediaWiki\HookContainer\HookContainer->run(string, array)
#5 /srv/mediawiki/php-1.41.0-wmf.15/includes/user/DefaultOptionsLookup.php(115): MediaWiki\HookContainer\HookRunner->onUserGetDefaultOptions(array)
#6 /srv/mediawiki/php-1.41.0-wmf.15/includes/user/UserOptionsManager.php(135): MediaWiki\User\DefaultOptionsLookup->getDefaultOptions()
#7 /srv/mediawiki/php-1.41.0-wmf.15/includes/user/UserOptionsLookup.php(51): MediaWiki\User\UserOptionsManager->getDefaultOptions()
#8 /srv/mediawiki/php-1.41.0-wmf.15/extensions/Math/src/HookHandlers/ParserHooksHandler.php(172): MediaWiki\User\UserOptionsLookup->getDefaultOption(string)
#9 /srv/mediawiki/php-1.41.0-wmf.15/includes/HookContainer/HookContainer.php(153): MediaWiki\Extension\Math\HookHandlers\ParserHooksHandler->onParserOptionsRegister(array, array, array)
#10 /srv/mediawiki/php-1.41.0-wmf.15/includes/HookContainer/HookRunner.php(3018): MediaWiki\HookContainer\HookContainer->run(string, array)
#11 /srv/mediawiki/php-1.41.0-wmf.15/includes/parser/ParserOptions.php(1215): MediaWiki\HookContainer\HookRunner->onParserOptionsRegister(array, array, array)
#12 /srv/mediawiki/php-1.41.0-wmf.15/includes/parser/ParserOptions.php(1262): ParserOptions::getDefaults()
#13 /srv/mediawiki/php-1.41.0-wmf.15/includes/parser/ParserOptions.php(1064): ParserOptions->initialiseFromUser(User, LanguageEn)
#14 /srv/mediawiki/php-1.41.0-wmf.15/includes/parser/ParserOptions.php(1074): ParserOptions->__construct(User, LanguageEn)
#15 /srv/mediawiki/php-1.41.0-wmf.15/includes/jobqueue/jobs/ParsoidCachePrewarmJob.php(106): ParserOptions::newFromAnon()
#16 /srv/mediawiki/php-1.41.0-wmf.15/includes/jobqueue/jobs/ParsoidCachePrewarmJob.php(140): ParsoidCachePrewarmJob->doParsoidCacheUpdate()
#17 /srv/mediawiki/php-1.41.0-wmf.15/extensions/EventBus/includes/JobExecutor.php(79): ParsoidCachePrewarmJob->run()
#18 /srv/mediawiki/rpc/RunSingleJob.php(77): MediaWiki\Extension\EventBus\JobExecutor->execute(array)
#19 {main}
```
==== Impact ====
==== Notes ====
Noticed during deploy of {T340243} to group0.
Spitballing with tags.
User-authored CSS, including CSS in Gadgets, cannot use Less (per T56864#6153179). This means that the Codex design tokens cannot be used there, because MediaWiki currently only makes these available as Less variables.
Implementation options include:
1. Magically transform user-authored CSS to substitute uses of a token with that token's value
1. Less-style placeholders: transform `color: @color-progressive;` to `color: #36c;`
2. CSS variable-style placeholders: transform `color: var( --color-progressive );` to `color: #36c`
2. Use real CSS variables
1. Create a ResourceLoader module that contains all Codex design tokens as CSS variables (i.e. its contents look like `:root { --color-progressive: #36c; --color-destructive: #d33; etc }`). Its size would be 17 KB (4.8 KB after gzip).
2. Detect which variables each gadget uses (by scanning its CSS for occurrences of `var( --something )`) and magically output the variables it needs alongside it. For example, if the Gadget's CSS contains `var( --color-progressive )`, we would add `:root { --color-progressive: #36c; }`
NOTE: The solutions for T355244 (TemplateStyles) and this one (Gadgets) may overlap significantly, depending on how they're implemented.
ResourceLoader currently does not allow .vue files to be used in on-wiki modules (only .js, .css and .json) files. We want to allow .vue files, but we don't want to allow Less (via `<style lang="less">`) in these, only CSS. This is because we decided not to make Less available in user-authored modules in T56864#6153179, for fear that arbitrary user-authored Less code could take arbitrarily long to execute.
Because all the code for .vue file handling is currently in FileModule, some of it will need to be moved to Module, while preserving the ability of FileModule to allow Less to be used and the ability of WikiModule to forbid it.
[ ] Add a content model for .vue pages, with the same special treatment as .js pages
[ ] Move (most) .vue handling code from FileModule to Module
[ ] Allow .vue pages to be used in WikiModule
[ ] Do not allow Less to be used in WikiModule (but continue to allow it in FileModule)
Please change the namespace aliases on diq.wikipedia. The discussion is [[https://diq.wikipedia.org/wiki/Wikipedia:Portal%C3%AA_cemati#Change_namespace_aliases|here]].
- Bağse > Xısusi
- Vaten > Werênayış
- Karber vaten > Werênayışê karberi
- $1 vaten > Werênayışê $1
- Wikipedia > Wikipediya
- Dosya vaten > Werênayışê dosya
- MediaWiki > MedyaWiki
- MediaWiki vaten > Werênayışê MedyaWikiyi
- Şablon vaten > Werênayışê şabloni
- Desteg > Peşti
- Desteg vaten > Werênayışê peşti
- Kategori > Kategoriye
- Kategori vaten > Werênayışê kategoriye
- Portal vaten > Werênayışê portali
- Modul vaten > Werênayışê moduli
- Halet > Hacet
- Halet vaten > Werênayışê hacetan
- Halet şınasnayış > Şınasnayışê hacetan
- Halet şınasnayış vaten > Werênayışê şınasnayışê hacetan
Hello. Please assign the following names to the Slovenian localization of namespaces. Please also retain functional the current names.
Most pressing (currently in use on Slovenian Wikimedia wikis):
| 6|File|Datoteka (previously Slika = Image)
| 710|TimedText|Podnapisi
| 711|TimedText talk|Pogovor o podnapisih
| 2300|Gadget|Pripomoček
| 2301|Gadget talk|Pogovor o pripomočku
| 2302|Gadget definition|Opredelitev pripomočka
| 2303|Gadget definition talk|Pogovor o opredelitvi pripomočka
Following are localized names of other namespaces and MediaWiki extensions. Please apply them as applicable.
|-2|Media|Predstavnost
|16|Expression|Izraz
|17|Expression talk|Pogovor o izrazu
|24|DefinedMeaning|Opredeljeni pomen
|25|DefinedMeaning talk|Pogovor o opredeljenem pomenu
|100|Relation|Relacija
|101|RelationTalk|Pogovor o relaciji
|102|Property|Lastnost
|103|Property talk|Pogovor o lastnosti
|104|Type|Vrsta
|105|Type talk|Pogovor o vrsti
|108|Concept|Koncept
|109|Concept talk|Pogovor o konceptu
|112|Rule|Pravilo
|113|Rule talk|Pogovor o pravilu
|114|smw/schema|smw/shema
|115|smw/schema talk|smw/pogovor o shemi
|106|Form|Obrazec
|107|Form talk|Pogovor o obrazcu
|110|Forum|Forum talk
|111|Forum talk|Pogovor o forumu
|120|Item|Predmet
|121|Item talk|Pogovor o predmetu
|122|Property|Lastnost
|123|Property talk|Pogovor o lastnosti
|124|Query|Poizvedba
|125|Query talk|Pogovor o poizvedbi
|146|Lexeme|Leksem
|147|Lexeme talk|Pogovor o leksemu
|170|Filter|Filter
|171|Filter talk|Pogovor o filtru
|200|Grants|Dotacije
|201|Grants talk|Pogovor o dotacijah
|202|Research|Raziskava
|203|Research talk|Pogovor o raziskavi
|206|UserWiki|Uporabnik wikija
|207|UserWiki talk|Pogovor o uporabniku wikija
|202|User profile|Profil uporabnika
|203|User profile talk|Pogovor o profilu uporabnika
|234|XML|XML
|235|XML talk|Pogovor o XML
|250|Page|Stran
|251|Page talk|Pogovor o strani
|252|Index|Kazalo
|253|Index talk|Pogovor o kazalu
|274|Widget|Gradnik
|275|Widget talk|Pogovor o gradniku
|280|JSApplet|JS aplet
|281|JSApplet talk|Pogovor o JS apletu
|300|Poll|Anketa
|301|Poll talk|Pogovor o anketi
|400|Video|Video
|401|Video talk|Pogovor o videu
|420|GeoJSON|GeoJSON
|421|GeoJSON talk|Pogovor o GeoJSON
|430|Quiz|Kviz
|431|Quiz talk|Pogovor o kvizu
|450|Boilerplate|Šablona
|451|Boilerplate talk|Pogovor o šabloni
|460|Campaign|Kampanja
|461|Campaign talk|Pogovor o kampanji
|470|Schema|Shema
|471|Schema talk|Pogovor o shemi
|482|Config|Konfiguracija
|483|Config talk|Pogovor o konfiguraciji
|486|Data|Podatki
|487|Data talk|Pogovor o podatkih
|484|Graph|Grafikon
|485|Graph talk|Pogovor o grafikonu
|486|Notebook|Beležnica
|491|GwToolset talk|Pogovor o GWToolset
|492|File annotations|Označitve datoteke
|493|File annotations talk|Pogovor o označitvah datoteke
|498|Nova Resource|Vir Nova
|499|Nova Resource talk|Pogovor o viru Nova
|501|Blog talk|Pogovor o blogu
|502|User blog|Uporabniški blog
|503|User blog talk|Pogovor o uporabniškem blogu
|600|UserBox|Uporabniško polje
|601|UserBox talk|Pogovor o uporabniškem polju
|620|Draft|Osnutek
|621|Draft talk|Pogovor o osnutku
|640|EntitySchema|Shema entitet
|641|EntitySchema talk|Pogovor o shemi entitet
|667|Heira talk|Pogovor o Heiri
|690|Action|Dejanje
|691|Action talk|Pogovor o dejanju
|692|Label|Oznaka
|693|Label talk|Pogovor o oznaki
|700|Link|Povezava
|701|Link talk|Pogovor o povezavi
|730|AccessControlGroup|Skupina nadzora dostopa
|731|AccessControl Group talk|Pogovor o skupini nadzora dostopa
|800|Interpretation|Interpretacija
|801|Interpretation talk|Pogovor o interpretaciji
|807|Moustache talk|Pogovor o Moustache
|830|SecurePoll talk|Pogovor o SecurePoll
|844|CommentStreams talk|Pogovor o CommentStreams
|866|CNBanner|Centralna pasica
|867|CNBanner talk|Pogovor o centralni pasici
|1198|Translations|Prevodi
|1199|Translations talk|Pogovor o prevodih
|1503|Blog talk|Pogovor o blogu
|1504|Book|Knjiga
|1505|Book talk|Pogovor o knjigi
|1506|SocialEntity|Socialna entiteta
|1507|SocialEntity talk|Pogovor o socialni entiteti
|1704|Story|Zgodba
|1705|Story talk|Pogovor o zgodbi
| 90|Thread|Nit
| 91|Thread talk|Pogovor o niti
| 92|Summary|Povzetek
| 93|Summary talk|Pogovor o povzetku
| 108|Book|Knjiga
| 109|Book talk|Pogovor o knjigi
| 442|Course|Tečaj
| 443|Course talk|Pogovor o tečaju
| 444|Institution|Ustanova
| 445|Institution talk|Pogovor o ustanovi
| 446|Education Program|Izobraževalni program
| 2600|Topic|Tema
| 2700|Genealogy|Genealogija
| 2701|Genealogy talk|Pogovor o genealogiji
| 2702|Genealogy template|Genealoška predloga
| 2703|Genealogy template talk|Pogovor o genealoški predlogi
| 2704|Genealogy form|Genealoški obrazec
| 2705|Genealogy form talk|Pogovor o genealoškem obrazcu
| 2900|Map|Zemljevid
| 2901|Map talk|Pogovor o zemljevidu
| 5500|Newsletter|Novičnik
| 5501|Newsletter talk|Pogovor o novičniku
| 5751|Test talk|Pogovor o testu
| 5770|Speech recording|Posnetek govora
| 5771|Speech recording talk|Pogovor o posnetku govora
| 5772| Pronunciation lexicon|Leksikon izgovarjave
| 5773|Pronunciation lexicon talk|Pogovor o leksikonu izgovarjave
| 7010|Material|Gradivo
| 7011|Material talk|Pogovor o gradivu
| 7020|Device|Naprava
| 7021|Device talk|Pogovor o napravi
| 7022|Software|Programje
| 7023|Software talk|Pogovor o programju
| 7030|Location|Lokacija
| 7031|Location talk|Pogovor o lokaciji
| 7040|File type|Vrsta datoteke
| 7041|File type talk|Pogovor o vrsti datoteke
| 7042|DataType|Vrsta podatkov
| 7043|DataType talk|Pogovor o vrsti podatkov
| 7051|OU Talk|Pogovor o OU
| 7060|Project|Projekt
| 7061|Project talk|Pogovor o projektu
| 7070|Person|Oseba
| 7071|Person talk|Pogovor o osebi
| 7080|Model|Model
| 7081|Model talk|Pogovor o modelu
| 7100|LabNote|Laboratorijski zapis
| 7101|LabNote Talk|Pogovor o laboratorijskem zapisu
| 7110|LabProcess|Laboratorijski postopek
| 7111|LabProcess Talk|Pogovor o laboratorijskem postopku
| 7200|OsiTemplate|Predloga OSI
| 7201|OsiTemplate Talk|Pogovor o predlogi OSI
| 7210|OsiForm|Obrazec OSI
| 7211|OSIForm talk|Pogovor o obrazcu OSI
| 7300|Field|Področje
| 7301|Field Talk|Pogovor o področju
| 7310|Term|Izraz
| 7311|Term talk|Pogovor o izrazu
| 7320|Statement|Izjava
| 7321|Statement talk|Pogovor o izjavi
| 7331|CR talk|Pogovor o CR
| 10000|Data|Podatki
| 10002|UserData|Uporabniški podatki
| 10010|Schema|Shema
| 10011|Schema talk|Pogovor o shemi
| 10030|DataType|Vrsta podatkov
| 10031|DataType talk|Pogovor o vrsti podatkov
Archived:
| 120|Cite|Navedek
| 121|Cite talk|Pogovor o navedku
| 140|Deletion|Izbris
| 200|Deletion discussion|Pogovor o izbrisu
| 160|UserGroup|Uporabniška skupina
| 248|Annotation|Označitev
| 249|Annotation talk|Pogovor o označitvi
| 262|Math|Matematika
| 263|Math talk|Pogovor o matematiki
| 351|Mooc talk|Pogovor o Mooc
| 401|Wiki2LaTeX talk|Pogovor o Wiki2LaTeX
| 446|Education Program|Izobraževalni program
| 447|Education Program talk|Pogovor o izobraževalnem programu
| 481|Zero talk|Pogovor o Zero
| 581|XML talk|Pogovor o XML
| 582|Schema|Shema
| 583|Schema talk|Pogovor o shemi
| 585|XSLT talk|Pogovor o XSLT
| 586|Editor|Urejevalec
| 587|Editor talk|Pogovor o urejevalcu
| 600|NagiosTemplate|Predloga Nagios
| 601|NagiosTemplate talk|Pogovor o predlogi Nagios
| 602|NagiosHostType|Vrsta gostitelja Nagios
| 603|NagiosHostType talk|Pogovor o vrsti gostitelja Nagios
| 604|NagiosCommand|Ukaz Nagios
| 605|NagiosCommand talk|Pogovor o ukazu Nagios
| 606|NagiosResource|Vir Nagios
| 607|NagiosResource talk|Pogovor o viru Nagios
| 608|NagiosServiceComand|Servisni ukaz Nagios
| 609|NagiosServiceCommand talk|Pogovor o servisnem ukazu Nagios
| 730|GitAccess root|Koren dostopa Git
| 731|GitAccess root talk|Pogovor o korenu dostopa Git
| 811|Jade talk|Pogovor o Jade
| 815|R talk|Pogovor o R
| 1301|PackageForce talk|Pogovor o PackageForce
Thank you!
Go to https://ace.wikipedia.org/w/api.php?action=query&list=gadgets&gaprop=id|metadata|desc
Output for scripts has an unexpected dangling/trailing whitespace for script filename in `"MediaWiki:Gadget-HotCat.js "`:
```
{
"id": "HotCat",
"metadata": {
"settings": {
"rights": [],
"skins": [],
"actions": [],
"category": "editing-gadgets"
},
"module": {
"scripts": [
"MediaWiki:Gadget-HotCat.js "
],
"styles": [],
"datas": [],
"dependencies": [],
"peers": [],
"messages": []
}
},
"desc": "Menambahkan, menghapus, dan mengubah kategori dengan saran (<a href=\"https://en.wikipedia.org/wiki/User:TheDJ/HotCat\" class=\"extiw\" title=\"en:User:TheDJ/HotCat\">HotCat</a>)"
},
```
**Steps to replicate the issue** (include links if applicable):
* https://de.wikipedia.org/w/api.php?action=query&list=querypage&qppage=GadgetUsage&qplimit=max
* https://es.wikipedia.org/w/api.php?action=query&list=querypage&qppage=GadgetUsage&qplimit=max
**What happens?**:
`"title": "Spezial:Badtitle/NS1346:gadget-Rechtschreibpruefung"`
`"title": "Especial:Badtitle/NS777:gadget-CorrectorOrtografico"`
**What should have happened instead?**:
Not entirely sure, on [[https://en.wikipedia.org/w/api.php?action=query&list=querypage&qppage=GadgetUsage&qplimit=max|enwiki]] it returns `"title": "Gadget:gadget-Navigation popups"`. ~~But Gadget: is no valid namespace on enwiki either me thinks.~~ Valid namespace, unused though so arguably still wrong.
On other projects the value for "ns" is the number of active users. On enwiki it's always 2300. See also T120895.
There should be a way for icons to be accessible to on-wiki code. Currently, they are only available for extensions and other ResourceLoader modules via the CodexModule php class.
Perhaps add a simple API endpoint to get the icons?
Hello,
Kindly update the namespace translations for Kashmiri Wikipedia as shown.
| Name | New namespace translation |Associated Talk
| ---- | ---- | ----
| Article |مَضموٗن | کَتھ
| Template |فرما | فرما کَتھ
| User |رُکُن | رُکُن کَتھ
| Media wiki |میٖڈیاوِکی | میٖڈیاوِکی کَتھ
| Gadget |آلہٕ | آلہٕ کَتھ
| Module |ماڈیوٗل | ماڈیوٗل کَتھ
| Help | مَدَتھ | مَدَتھ کَتھ
| File | فَیِل| فَیِل کَتھ
|Gadget definition | آلہٕ تَعارُف | آلہٕ تَعارُف کَتھ
| Special | خاص | خاص کَتھ
Local Discussion: [[https://ks.m.wikipedia.org/wiki/%D9%88%D9%90%DA%A9%DB%8C%D9%96%D9%BE%DB%8C%D9%96%DA%88%DB%8C%D8%A7:%D8%A7%D8%A0%D8%B3%D9%8E%D9%85%D8%A8%D9%8E%D9%84%DB%8C_(%D8%AA%D9%8E%DA%A9%D9%86%DB%8C%D9%96%DA%A9%DB%8C) |Here]]
Thankyou.
**List of steps to reproduce**:
* Specify `actions=view,submit` for a gadget in definitions
**What happens?**:
The gadget only loads on action=view.
**What should happen instead?**:
It should load on action=submit too.
The Gadgets extension recently added support for gadgets to conditionally load based on page action ('view', 'edit', etc).[1] However, gadgets configured to load on action=edit don't currently load when VE or 2017WE is used, because VE doesn't reload the full page and builds the editing interface entirely via AJAX, so the server-side onBeforePageDisplay hook through which Gadgets adds the modules is never invoked.
Solution:
- VE could [[https://en.wikipedia.org/w/api.php?action=query&format=json&list=gadgets&gaprop=id%7Cmetadata&gaenabledonly=1 | query the API for enabled gadgets]] that use actions=edit, and load them using `mw.loader`.
[1]: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/747112, T204201
Currently, all JS/CSS/JSON files in a gadget definition must be from the local wiki. It should be possible to specify files from another wiki on the WMF cluster.
And/or equivalently, it should be possible to define a gadget which is entirely loaded from another wiki – essentially a "pointer" gadget. This could be marked as hidden and used as a dependency for a user-facing gadget.
**Usecases**
1. i18n/l10n: Generally, gadgets would want to load the core part from another wiki, and specify a local file with i18n strings and per-wiki configurations.
2. Use of foreign libraries: A gadget on frwiki or dewiki should be able to use enwiki's [[ https://en.wikipedia.org/wiki/MediaWiki:Gadget-morebits.js | Morebits.js ]] library without having to maintain a local copy.
Example:
`*HotCat [ ResourceLoader ] | HotCat.js@commonswiki | HotCat.css@commonswiki | HotCat-enwiki-config.json` (MediaWikiGadgetsDefiniton is too limiting w.r.t. syntax, but the GadgetDefinitionNamespace syntax can be made more systematic)
Or equivalently,
Core hidden gadget which is a pointer to a gadget on foreign wiki.
`*HotCat-core [ ResourceLoader | source = HotCat@commonswiki | hidden ]`
The user-facing gadget, which just add a site config file to the core hidden gadget
`*HotCat [ ResourceLoader | dependencies = ext.gadget.HotCat-core ] | HotCat-enwiki-config.json`
Validation warnings to show:
1. Gadget with type=styles having non-CSS files
2. Packaged gadgets not having at least one JS file (after T198758)
3. Non-packaged gadgets having JSON files (after T198758)
4. Style-only gadgets having peers
5. Peer gadgets not being styles-only gadgets
6. Scripts/styles/datas not being of JS/CSS/JSON contentmodel respectively, or not existing altogether
7. Invalid page actions specified
8. Non-existent namespace numbers specified (after https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/624517/) (done)
9. Invalid targets specified
10. Invalid content models (specified as load condition)
11. Default gadget requiring ES6
Currently all of these validations do take place at some point, but no warnings are shown to the user. The problematic parts in gadget definitions are silently ignored.
**Approaches**
1. Expand GadgetDefinitionValidator (for gadget definition namespace only) – Pre-save hook that blocks the save in case of issues. The existence/contentmodel of the resource files could change, so it may not be a good idea to validate those here.
2. Show warnings in Special:Gadgets – These can cover all kinds of validations.
I think it is time we remove the non-RL mode from Gadgets.
1. Turn makeLegacyWarning into a log deprecate.
2. Track on the deprecation dashboard.
3. Inform wikis of their old/broken gadgets
4. When satisfactory, remove code of the old legacy gadgets from the extension.
[[https://docs.google.com/document/d/1MhckkPg9c6L-fkZNgeMfcvOrRq2iNUKCFnDPXUgdwCI/edit?usp=sharing | Decision Statement Overview Artifact & Decision Record ]]
# What is the problem or opportunity?
We currently log JavaScript errors that our users encounter. This helps us make sure the code across our repositories are well maintained and resilient (to connections, skins, across pages).
The same tooling also helps us identify errors in gadgets maintained by editors on wiki.
Problematically we cannot easily tell the difference between errors originating in our code and errors originating in gadgets without manually triaging or fixing every issue. This is costly work. This manual work has been done however and at least 20% of our errors originate in gadgets.
This is a problem as editors currently do not have access to these logs without signing an NDA, may not share the same motivation/values around code quality or may have written their gadgets some time ago and have since left our projects. Where Wikimedia-staff have fixed errors, there has sometimes been friction has some users take issue with staff editing scripts that editors see themselves as "owners".
Historically Wikimedia has set the informal expectation that it does not maintain community gadgets, however, if gadget errors are equal alongside Wikimedia code errors, it's hard to ignore them. When gadgets change jQuery version or introduce other code that breaks experiences for users, it becomes hard to ignore.
It would be useful to get interested parties involved in a conversation to reflect on the status quo, how much we should care and if we don't care modify our code to reflect this.
Goals:
1) Define a policy around gadget/user scripts that lives on a wiki page somewhere. It should make clear to WMF staff and gadget developers expectations around who can edit, what is expected with regards to quality and errors, and what should happen to gadgets where the maintainer has retired or lost interest.
2) Our error logging system should be built around this policy, potentially programatically distinguishing between WMF errors and gadget errors. This may come with trade-offs such as no longer running gadgets in global scope.
3) Gadget developers should be able to improve their code if they wish. It should be decided whether the current tooling with NDA i sufficient or if appropriate tooling needs to be provided.
4) The existing gadget system should be modified if necessary to reflect the new policy.
# What does the future look like if it's achieved?
* WMF spends less time triaging and fixing broken gadgets
* When building and deploying new products WMF is able to clearly determine impact of changes that break gadgets
* Users gadgets do not suddenly stop working
* User gadget developers and WMF staff enjoy a better relationship, better communication.
# What happens if we do nothing
Certain staff members including myself will continue to try to prop up the system by keeping an eye on issues on-wiki and fixing them as they arise. They will do this until they lose interest/burn out.
When nobody is looking at errors, unchecked the amount of errors will rise, leading to alerts in grafana and noise in the error logging tooling will grow large.
Eventually this might lead to a high volume of errors that make the tooling useless, and potentially break the EventLogging platform it's built upon. If this ever happens, worse case scenario is that this valuable infrastructure will lose its value, and be turned off, and we will go back to how it was before we had error logging.
# More background
## Blog posts
* https://jdlrobson.com/posts/2020-09-28_diving-into-wikipedia-s-ocean-of-errors-a6b6be92bf2e?r=jt
* https://diff.wikimedia.org/2021/03/08/sailing-steady%E2%80%8A-%E2%80%8Ahow-you-can-help-keep-wikimedia-sites-error-free/
## Motivation for this ticket
https://gerrit.wikimedia.org/g/mediawiki/core/+/52a0f90a9bd0888078a2bab8f95dc4018539bfb0/resources/src/startup/mediawiki.js#1940
In a 12 hr period 251 / 2,530 production errors came from gadgets e.g. Error: module already implemented: ext.gadget.Cat-a-lot - none of these are actionable as it's not clear how they were loaded. Note the number is likely a lot larger as many of these are likely to be surfacing as "Script error" due to cross domain loading.
Presumably, this is because modules can be loaded via different means from different projects via global scripts.
If a module is already implemented I would prefer it logs a warning rather than an error. Do we really need to throw an error here (asking ResourceLoader expert)? If so, could we at least disable the error logging for modules that are gadgets
backtrace :
```
...batch conversion of user_options: MWException from line 260 of C:\inetpub\wwwroot\mediawiki\includes\Revision\RevisionStore.php: Content model must be stored in the database for multi content revision migration.
#0 C:\inetpub\wwwroot\mediawiki\includes\Revision\RevisionStoreFactory.php(141): MediaWiki\Revision\RevisionStore->setContentHandlerUseDB(false)
#1 C:\inetpub\wwwroot\mediawiki\includes\ServiceWiring.php(718): MediaWiki\Revision\RevisionStoreFactory->getRevisionStore()
#2 C:\inetpub\wwwroot\mediawiki\includes\libs\services\ServiceContainer.php(458): Wikimedia\Services\ServiceContainer->{closure}(Object(MediaWiki\MediaWikiServices))
#3 C:\inetpub\wwwroot\mediawiki\includes\libs\services\ServiceContainer.php(427): Wikimedia\Services\ServiceContainer->createService('RevisionStore')
#4 C:\inetpub\wwwroot\mediawiki\includes\MediaWikiServices.php(933): Wikimedia\Services\ServiceContainer->getService('RevisionStore')
#5 C:\inetpub\wwwroot\mediawiki\includes\ServiceWiring.php(704): MediaWiki\MediaWikiServices->getRevisionStore()
#6 C:\inetpub\wwwroot\mediawiki\includes\libs\services\ServiceContainer.php(458): Wikimedia\Services\ServiceContainer->{closure}(Object(MediaWiki\MediaWikiServices))
#7 C:\inetpub\wwwroot\mediawiki\includes\libs\services\ServiceContainer.php(427): Wikimedia\Services\ServiceContainer->createService('RevisionLookup')
#8 C:\inetpub\wwwroot\mediawiki\includes\MediaWikiServices.php(917): Wikimedia\Services\ServiceContainer->getService('RevisionLookup')
#9 C:\inetpub\wwwroot\mediawiki\includes\Revision.php(76): MediaWiki\MediaWikiServices->getRevisionLookup()
#10 C:\inetpub\wwwroot\mediawiki\includes\Revision.php(139): Revision::getRevisionLookup()
#11 C:\inetpub\wwwroot\mediawiki\extensions\Gadgets\includes\MediaWikiGadgetsDefinitionRepo.php(139): Revision::newFromTitle(Object(Title))
#12 C:\inetpub\wwwroot\mediawiki\extensions\Gadgets\includes\MediaWikiGadgetsDefinitionRepo.php(108): MediaWikiGadgetsDefinitionRepo->fetchStructuredList()
#13 C:\inetpub\wwwroot\mediawiki\includes\libs\objectcache\wancache\WANObjectCache.php(1423): MediaWikiGadgetsDefinitionRepo->{closure}(false, 86400, Array, NULL)
#14 C:\inetpub\wwwroot\mediawiki\includes\libs\objectcache\wancache\WANObjectCache.php(1278): WANObjectCache->fetchOrRegenerate('wiki:gadgets-de...', 86400, Object(Closure), Array)
#15 C:\inetpub\wwwroot\mediawiki\extensions\Gadgets\includes\MediaWikiGadgetsDefinitionRepo.php(115): WANObjectCache->getWithSetCallback('wiki:gadgets-de...', 86400, Object(Closure), Array)
#16 C:\inetpub\wwwroot\mediawiki\extensions\Gadgets\includes\MediaWikiGadgetsDefinitionRepo.php(31): MediaWikiGadgetsDefinitionRepo->loadGadgets()
#17 C:\inetpub\wwwroot\mediawiki\extensions\Gadgets\includes\GadgetRepo.php(71): MediaWikiGadgetsDefinitionRepo->getGadgetIds()
#18 C:\inetpub\wwwroot\mediawiki\extensions\Gadgets\includes\GadgetHooks.php(44): GadgetRepo->getStructuredList()
#19 C:\inetpub\wwwroot\mediawiki\includes\Hooks.php(174): GadgetHooks::userGetDefaultOptions(Array)
#20 C:\inetpub\wwwroot\mediawiki\includes\Hooks.php(202): Hooks::callHook('UserGetDefaultO...', Array, Array, NULL)
#21 C:\inetpub\wwwroot\mediawiki\includes\user\User.php(1723): Hooks::run('UserGetDefaultO...', Array)
#22 C:\inetpub\wwwroot\mediawiki\includes\user\User.php(1735): User::getDefaultOptions()
#23 C:\inetpub\wwwroot\mediawiki\maintenance\convertUserOptions.php(96): User::getDefaultOption('quickbar')
#24 C:\inetpub\wwwroot\mediawiki\maintenance\convertUserOptions.php(67): ConvertUserOptions->convertOptionBatch(Object(Wikimedia\Rdbms\ResultWrapper), Object(Wikimedia\Rdbms\MaintainableDBConnRef))
#25 C:\inetpub\wwwroot\mediawiki\includes\installer\DatabaseUpdater.php(1196): ConvertUserOptions->execute()
#26 C:\inetpub\wwwroot\mediawiki\includes\installer\DatabaseUpdater.php(490): DatabaseUpdater->doMigrateUserOptions()
#27 C:\inetpub\wwwroot\mediawiki\includes\installer\DatabaseUpdater.php(454): DatabaseUpdater->runUpdates(Array, false)
#28 C:\inetpub\wwwroot\mediawiki\maintenance\update.php(205): DatabaseUpdater->doUpdates(Array)
#29 C:\inetpub\wwwroot\mediawiki\maintenance\doMaintenance.php(99): UpdateMediaWiki->execute()
#30 C:\inetpub\wwwroot\mediawiki\maintenance\update.php(277): require_once('C:\\inetpub\\wwwr...')
#31 {main}
```
(note : IIS on Windows Server...)
can be circumvented by:
# disabling Gadgets extension in LocalSettings.php
# running update.php
# enabling Gadgets again
# running update.php again
See : https://www.mediawiki.org/wiki/Topic:Vsrm7u0nego5seo2
A common subtype of community-maintained Javascript is one that adds interactive features to a certain template (examples include the Teahouse ask-a-question feature on enwiki, [[https://meta.wikimedia.org/wiki/Meta:AddMe|AddMe]] and [[https://meta.wikimedia.org/wiki/Meta:FormWizard|FormWizard]] on meta, the tabbed interface used at [[https://www.mediawiki.org/wiki/API:Login#Sample_code|mw:API:Login]]). These scripts are loaded and executed on every page and do some cheap test (such as checking whether some CSS class is present on the page) to determine whether to perform their main functionality. This is bad both for performance (all these scripts are loaded on all pages, even though they are only needed on a tiny fraction of pages, and usually ones that are only relevant for editors and as such never visited by most users of the wiki) and for robustness (bugs in these scripts would affect users viewing unrelated pages). Ideally scripts would only be loaded on pages where they are actually needed.
The infrastructure for that is mostly in place already - the Gadgets extension declares ResourceLoader modules for gadgets, gadgets can be marked as hidden (unavailable via the preferences page) and parser plugins such as tag extensions and parserfunctions can load ResourceLoader modules, so all that is needed is a parser function that does tell the parser to load the specified gadget, so it can be added to the relevant template. Something like `{{#gadget:<gadget name>}}` which would then load the `ext.gadget.<gadget name>` module.
T39230 proposes to have a standard way to create QUnit tests, and run them from a Special page. While that alone would be an improvement, it would be even better if you could run unit tests when editing a script, //before// saving the page.
====Use cases====
As an interface admin, when I am implementing an edit request for a script, I want to run unit tests against the new version of the script before saving so that I don't break existing functionality.
As a userscript author, given that a script in my userspace has a testcase that fails, when I am editing that script, I want to run the unit tests against the new version of the script before saving so that I can verify the changes fix the failing testcase (and do not cause any other tests to fail).
====Concept====
An extension that provides unit testing capability for gadgets/scripts, using QUnit. Unit tests are defined on a script's /testcases.js subpage.
Tests are run when editing, after previewing or showing changes (`action=submit`) -- or perhaps a new button "Run unit tests".
To run tests, load QUnit js and css, concatenate the editor textbox content and the content of the testcases subpages (so they are within the same outer scope), and execute the resulting text as javascript.
There may need to restrictions on where this can operate for security:
- MediaWiki namespace should be okay - editing is restricted to interface admins
- `contentmodel:javascript` pages in your userspace should be okay - editing is restricted to yourself and interface admins
- Elsewhere could be problematic. The safest way would be to just not operate on these pages... but perhaps just having a confirmation box with a "scary" message (similar to [[https://en.wikipedia.org/wiki/MediaWiki:Jswarning|enwiki's MediaWiki:Jswarning]]) would be good enough, given that it's not really any worse than using `importScript` on your common.js
- Perhaps there should also be a note or warning that code entered into the textbox will be executed to run unit tests
Other considerations:
- The interface should show appropriate messages when viewing scripts and testcases pages: "This script appears to have unit tests at [...link...]", "Unit tests for this script can be created at [...link...]", "These are the unit tests for [...link...]"
- There should be a way to indicate ResourceLoader dependencies needed for unit tests, perhaps a comment like `/* dependencies mediawiki.api,mediawiki.util,oojs-ui-core,oojs-ui-windows */` at the top of the testcases page.
A userscript version of this concept exists at https://en.wikipedia.org/wiki/User:Evad37/WikiUnit.js , see also discussion at [[https://en.wikipedia.org/wiki/Wikipedia:Interface_administrators%27_noticeboard#Gadget_and_userscript_unit_testing|Wikipedia:Interface administrators' noticeboard#Gadget and userscript unit testing]].
(Not a blocker for wiki creation.)
The following strings shold be localised:
```name=Aliases
/** English (English) */
$specialPageAliases['en'] = [
'Gadgets' => [ 'Gadgets' ],
'GadgetUsage' => [ 'GadgetUsage' ],
];
```
```name=Namespaces
$namespaceNames['en'] = [
NS_GADGET => 'Gadget',
NS_GADGET_TALK => 'Gadget_talk',
NS_GADGET_DEFINITION => 'Gadget_definition',
NS_GADGET_DEFINITION_TALK => 'Gadget_definition_talk',
];
```
(Not a blocker for wiki creation.)
The following strings shold be localised:
```name=Aliases
/** English (English) */
$specialPageAliases['en'] = [
'Gadgets' => [ 'Gadgets' ],
'GadgetUsage' => [ 'GadgetUsage' ],
];
```
```name=Namespaces
$namespaceNames['en'] = [
NS_GADGET => 'Gadget',
NS_GADGET_TALK => 'Gadget_talk',
NS_GADGET_DEFINITION => 'Gadget_definition',
NS_GADGET_DEFINITION_TALK => 'Gadget_definition_talk',
];
```
(Not a blocker for wiki creation.)
The following strings shold be localised:
```name=Aliases
/** English (English) */
$specialPageAliases['en'] = [
'Gadgets' => [ 'Gadgets' ],
'GadgetUsage' => [ 'GadgetUsage' ],
];
```
```name=Namespaces
$namespaceNames['en'] = [
NS_GADGET => 'Gadget',
NS_GADGET_TALK => 'Gadget_talk',
NS_GADGET_DEFINITION => 'Gadget_definition',
NS_GADGET_DEFINITION_TALK => 'Gadget_definition_talk',
];
```
The following strings need to be localised:
```name=Aliases
/** English (English) */
$specialPageAliases['en'] = [
'Gadgets' => [ 'Gadgets' ],
'GadgetUsage' => [ 'GadgetUsage' ],
];
```
```name=Namespaces
$namespaceNames['en'] = [
NS_GADGET => 'Gadget',
NS_GADGET_TALK => 'Gadget_talk',
NS_GADGET_DEFINITION => 'Gadget_definition',
NS_GADGET_DEFINITION_TALK => 'Gadget_definition_talk',
];
```
A recent discussion on en.WP highlighted that we do not have any sort of table of contents in the user preferences tabs (and specifically the Gadgets tab), which can result in difficulty navigating a particular tab on Special:Preferences. ([[https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Gadgets-definition&oldid=885812291#Add_table_of_contents? |permalink]]) While we might be able to control user preferences such that there are fewer rather than more, the Gadgets tab doesn't really have the luxury of "remove gadgets" when it's more likely that we will continue to move more scripts to Gadget land (for many reasons, such as safety and trust).
This is just a wish, but as Gadgets 2.0 are not close to the finish (at least they seem to not be), it would be extremely helpful to introduce doc pages to js and css pages the same way as those work for Scribunto pages.
**Steps to reproduce**
# Create an item on Wikidata for a gadget shared across numerous projects
# Add gadget pages into it
**Expected behavior**
I would expect the interwiki be visible on a gadget page. I understand the gadget are in the MediaWiki namespace currently, which is not operated by Wikidata interwiki, but there should be an exception for Gadgets, where this would really helpful. You don't want to maintain a list of interwiki links on each MediaWiki project, which uses the copy of the original gadget code.
I also understand this may be one day solved with Gadgets 2.0, but since Tech news are quiet so long about any progress in this, I suppose it hasn't got such priority and will not be ready anytime soon.
This could be applicable to all *.js or *.css pages onwiki as the newly established interface admins would have easier job to track changes across Wikimedia projects and fix for example an issue in Mobile.css if someone on other project finds a bug in the shared/copied code.
One of most concerning attack vectors of MediaWiki users is via problematic javascript being added to user-scripts and gadgets. How do people review these kinds of edits? Can we model what a problematic javascript edit looks like? What kinds of changes need review?
The documentation on writing gadgets or converting old ones to work in VisualEditor (either mode) doesn't seem to be adequate. We should figure out how to improve it.
**Existing documentation:**
* https://www.mediawiki.org/wiki/VisualEditor/Gadgets
* https://www.mediawiki.org/wiki/VisualEditor/Gadgets/Add_a_tool
* https://www.mediawiki.org/wiki/VisualEditor/Gadgets/Creating_a_custom_command
**Expected outcome:**
People can write gadgets to do simple things without needing to get personal help.
**Actual results:**
We hear from people who say that they tried and failed, but nobody says that the existing documentation worked and covered everything they needed to know.
There are several large problems with how editor-controlled Javascript/CSS (user/site scripts/styles and gadgets) are used in MediaWiki:
* {T71445}: there is no code review process, which is both a security nightmare and a barrier to creating maintainer communities around scripts. Also no good way to test code changes before applying them.
* {T121470}: there is no good way of sharing the same resources between multiple sites (or, in the case of long-tail scripts that are not popular enough to become site scripts or gadgets, sharing between multiple users) - resulting in either outdated copies or performance-degrading sharing methods.
* {T39230} / {T53651}: there is no continuous integration style support (linting, unit tests, browser tests, documentation generation etc) for editor-controlled Javascript/CSS.
Moving the code to some external version control platform should be a good solution for some of these issues and at least a foundation for a good solution for the rest:
* code sharing would be trivial and easy to track
* many public code repositories (most notably Github) also serve as development platforms and provide excellent code review and continuous integration support (and issue management and various other things)
* while testing/debugging support would still have to be implemented on the MediaWiki side, pull requests / feature branches at least provide a sane basis for it (as opposed to the current state of the art for code review, which is pasting suggested changes to the talk page)
(frwiki is already [[https://fr.wikipedia.org/wiki/Discussion_Projet:JavaScript#Discussion_tech_.C3.A0_la_WikiConvention_et_maintenance_du_projet_JavaScript|working on]] moving their gadget code to git and might be interested in this. The [[https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2018/Prehackathon_Montpellier|2018 Montpellier pre-hackathon]] also has a related theme.)
Implementation proposal:
* Provide a configuration setting to associate a wiki with a list of repository providers.
* Provide a web configuration interface for associating wiki pages (`MediaWiki:*.js/css/json`, maybe `User:*.js/css/json`) with files in a git repository (on some specified branch/tag).
* Lock those pages from editing.
* Modify the appearance of these pages to give some hint of what's going on.
* Provide some kind of form for updating the pages associated to a certain repository to the latest version. This would work much like a normal edit (appear in recent changes etc.) so monitoring such code with the usual set of wiki tools would still be possible.
* Optionally, provide a webhook for listening to updates; when the code is updated in git, notify the maintainers (how would they be identified though)? Or even update automatically, although that might be a bad security-convenience tradeoff.
* Provide some [[https://www.mediawiki.org/wiki/Extension:TemplateSandbox|TemplateSandbox]]-like tool to override which branch the files are loaded from (for the purposes of testing pull requests). [[https://gerrit.wikimedia.org/r/#/c/340768/|gerrit 340768]] will make this fairly easy.
* Probably provide some sort of monitoring/reporting so that security engineers can get an easy overview of what repos to watch.
Currently, gadgets are identified by page name. Hence, when a gadget is renamed, the user preferences to have enabled this gadget is lost.
A feature to migrate a gadget would then be welcome to perform the following tasks:
# Gets the list of users having gadget A enabled
# Enable gadget B for these users
# Disable gadget A for these users
Hello, I want to ask to create a script that would replace the names of gadgets in the database in Russian Wikipedia, this is necessary for user settings which can disappear when simple renaming.
Use-case:
* Volunteer developers would like a tool that enables them to easily audit the code in gadgets and site-wide javascript (common.js / vector.js / monobook.js / mobile.js) (and perhaps also userscripts). This would enable them to focus their time on fixing deprecated or broken code, without having to spend many additional hours either manually testing gadgets, or looking through the raw code to try to identify errors.
Desired Outcome:
# provide some easy way to audit gadgets (or scripts in general).
# report the audit results to the wiki (either specific talkpage, or generalized specialpage, or even just a labs page that a bot could ping onwiki for updates)
This will help to avoid problems similar to the wikibits removal in April 2017, which led to widely unexpected problems, considering it followed a long deprecation period.
(**Please edit this task description directly, to improve it, and clarify options. @Quiddity is not dev, and might have written inaccuracies!**)
----
Notes:
(A) There's a bot at Commons that seems to do this [[https://commons.wikimedia.org/wiki/User:CommonsMaintenanceBot|User:CommonsMaintenanceBot]] - It makes [[https://commons.wikimedia.org/w/index.php?title=User_talk:Ellin_Beltz&curid=13248327&diff=242542659&oldid=242338354 |edits like this example]].
Bot Task description:
> Watching recent changes of MediaWiki JavaScript pages, running [[http://jshint.com/|JSHint]] over the old revision and the new revision, and generally notifying the editing user about issues, except they opted out; writing full report to a subpage of Commons User scripts (MediaWiki pages go to the message cache) and maintaining a table of scripts and their //JSHint// and //esprima// status (needs sysop flag for [[https://commons.wikimedia.org/wiki/Special:PermanentLink/126914654|deleting obsolete error reports of scripts that are valid]])
> [[https://commons.wikimedia.org/wiki/Commons:User_scripts/reports|Script Health Reports]]
> Programming language(s): JavaScript. Running on Node.js - source code available on [[https://github.com/Rillke/commons-maintenance-bot|GitHub]] (On labs: /data/project/commons-maintenance-bot/)
@Multichill notes: "Something like that, we just have to force it to fail on deprecation warnings"
----
(B) Also the [[https://www.mediawiki.org/wiki/Help:Extension:Linter|Extension:Linter]] model,
where errors are listed at a special page, e.g. [[https://www.mediawiki.org/wiki/Special:LintErrors|mw:Special:LintErrors]]
-----
See also: {T71519}
From https://www.mediawiki.org/wiki/Parsoid/Known_differences_with_PHP_parser_output#Differences_identified_via_visual_diff_testing
https://en.wikipedia.org/w/api.php?action=parse&oldid=XXXXX&prop=modules|jsconfigvars
doesn't return them
https://en.wikipedia.org/w/api.php?action=query&list=gadgets&gaprop=id%7Cmetadata
does, and I guess filter on "default" and skin "vector" or the empty list? where does that leave "MediaWiki:Gadget-featured-articles-links.css"?
Make a migration plan for [[ https://www.mediawiki.org/wiki/Gadgets_2.0 | Gadgets 2.0 ]].
1 - make sure it's running on CTech labs instance
2 - test it on beta cluster
3 - test it on test WP
4 - roll out to smaller wikis
Write up the exact steps for switching a wiki and figure out which wikis would be willing to try it out.
See https://gerrit.wikimedia.org/r/#/c/247869/ for existing Gadgets 2.0 code.
If converting to Gadgets 2.0 goes awry and we have to switch everything back, we'll need a reverse migration script that formats the gadgets back to 1.0.
See https://gerrit.wikimedia.org/r/#/c/247869/ for existing Gadgets 2.0 code.
Per T124943#2268762, it seems there is a bug where the first gadget imported via Gadgets 2.0 doesn't show up in GadgetManager. No idea if this bug affects the first gadget period, or just the first imported gadget (or just the Console gadget for some reason).
>>! In T125582#1993994, @TheDJ wrote:
> Comments
> * ...
> * Gadgetmanager wise, I don't see many problems.
> ** It's all jQuery UI, which we are trying to get rid off.. but it is fairly self contained, so I think that's ok for now, but is there a ticket for that ?
Before we switch any wikis over to using [[ https://www.mediawiki.org/wiki/Gadgets_2.0 | Gadgets 2.0 ]], we should have some community members test it out and give us feedback. Some specific questions to answer:
* Is the new GadgetManager intuitive?
* Are there any critical features that are missing?
* Notice any bugs or inconsistencies?
Send an email to Wikitech-l mailing list as well.
We should be able to get stats on how many users disable each default gadget, so that we can reconsider which ones should actually be turned off by default.
**See also**
* {T121133}
Re: the new [[Special:GadgetUsage]] page, e.g. https://commons.wikimedia.org/wiki/Special:GadgetUsage and the tasks that led to it ({T115152} and related)
It would be useful to track month-on-month changes for both columns, so that we could:
* spot usage spikes; and
* see when gadgets are steadily gaining popularity, vs plateau'd or declining.
See T120895#1864312 for the SQL query that is used to generate those columns.
* As a gadget developer, I want a standard way to customize gadgets (not copying local implementations from one wiki to another).
* As a gadget user, I want a nice UI to customize the gadgets I use, without having to learn how to edit a JS/CSS subpage.
The "gadgetprefs" (from [[https://www.mediawiki.org/wiki/User:Salvatore_Ingala/GSoC_2011_application|GSoC 2011]]) branch seems to implement that, but is rotting since 2011:
https://phabricator.wikimedia.org/diffusion/EGAD/history/gadgetprefs/
**See also**
* [[https://gerrit.wikimedia.org/r/#/c/4385/|Gerrit Change 4385]] - Abandoned
* {T42124}
* [[https://pl.wikipedia.org/wiki/MediaWiki:Gadget-gConfig.js|pl:MediaWiki:Gadget-gConfig.js]], maintained by @matmarex
* [[https://en.wikipedia.org/wiki/User:PerfektesChaos/js/preferencesGadgetOptions|en:User:PerfektesChaos/js/preferencesGadgetOptions]], maintained by @PerfektesChaos
On (backend) page request on enwiki, 'enwiki:gadgets-definition:7' is fetched from memcached. It's 53k of data. That is excessive.
MediaWiki: CSS/JS pages on any non-large wiki are usually a mess. Occasionally, we'll discover that wikis have been loading external resources for months and no one noticed. In addition, the local sysops maintaining those pages usually don't know JavaScript and are copy-pasting what someone else told them to do. Even when that's not the case, mistakes can result in code with [[https://szl.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&diff=prev&oldid=208782|obvious syntax errors]] being sent to readers for long periods of time.
Various proposals have floated around over the years. The wikitech-l threads have some good discussion on some of the reasons why this is difficult for smaller wikis.
* Wikitech-l:
* [[http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/74283|No longer allow gadgets to be turned on by default for all users on Wikimedia sites]] (specifically about Gadgets though)
* [[http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/79080/|Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)]]
* Wikimedia-l:
** [[http://thread.gmane.org/gmane.org.wikimedia.foundation/74166|Next steps regarding WMF<->community disputes about deployments]]
** [[http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/79055/|Superprotect user right, Comming to a wiki near you]]
**See Also**:
* {T39230} (bug 37230)
* {T53651} (bug 51651)
* {T71550}
* {T121470}
* {T165981}
* {T120886}
* {T171563}
>>! Problem statement by @Krinkle from T65532#7012174:
>
> A user should be able to easily understand when they are enabling a gadget that it will not work in their current skin. Eg. by not showing the choice at all, or by disabling it with an explanation why, or by otherwise explaining and softly discouraging enabling gadgets that would not be applied.
-------
>>! Original description by @He7d3r:
> After
> https://en.wikipedia.org/w/index.php?diff=602745335&oldid=602632745
> if I go to
> https://en.wikipedia.org/wiki/Special:Preferences?useskin=monobook#mw-prefsection-gadgets
> I still see the option "Vector classic typography (use only sans-serif in Vector skin)".
>
> On the other hand, if I change my skin to monobook and save my new preference, it disappears as expected. It seems to be missing some code to detect the URL parameter.
>
Gadget checkboxes should be able to be grayed out (inaccessible) dependent on if another gadget is on or off, if other extensions exist that gadgets are unable to use, or if they require a specific skin to work. For example, on en.wikipedia the current "Editing" section of the gadget tab on the preferences page looks like:
[[ https://commons.wikimedia.org/wiki/File:Special_Preferences_mw-prefsection-gadgets_(current).png | commons:File:Special_Preferences_mw-prefsection-gadgets_(current).png ]]
There should be a way to gray out functions, like:
[[ https://commons.wikimedia.org/wiki/File:Special_Preferences_mw-prefsection-gadgets_(proposed).png | commons:File:Special_Preferences_mw-prefsection-gadgets_(proposed).png ]]
If (in this instance) VisualEditor is enabled.
[15:52] <T13> VE Question. How is VE currently set up to handle users that have opted-in to gadgets that modify the editing window such as wikEd?
...
[15:54] <T13> Do those gadgets still load even though the hooks they use don't exist? Shouldn't having VE enabled disable those gadgets and grey out the optiobs for them in the gadgets tab of preferences?
[15:56] <T13> I'm guessing some of the "VE" bugs are caused by these gadgets trying to do what they no longer can.
...
[16:06] <mooeypoo> T13: I think most of the edit-related gadgets work on the action=edit condition, and ve goes with action=vedit
[16:07] <mooeypoo> but I am not sure :) you'll be safer getting the answer from the VE team
[16:09] <MatmaRex> T13: i'm not on the team, but i'm pretty sure that's the reason
[16:10] <MatmaRex> T13: basically there are two ways to detect if we're inedit mode - either look if 'action' is 'edit' or 'submit', or look for some elements that are parts of theedit form, like #wpTextbox1 (the main textbox)
[16:10] <MatmaRex> VE avoids them both
[16:11] <T13> I've seen questions on WP:THQ with a link to a screenshot of wikEd and the user thinking they were using VE. So, I was curious how it was handled.
[16:11] <T13> I'll add the suggestion to gray out the unusable with VE gadgets
[16:11] <mooeypoo> Ah, *that* kind of user errors. Hm. Not sure how you can handle those other than politely correct the user's false assumption
[16:11] <T13> On Bugzilla...
--------------------------
**Version**: unspecified
**Severity**: enhancement
It seems kind of convoluted that [[Special:Gadgets]] doesn't let me set my gadgets. It's already a Special page that lists every gadget. Having it load the Gadget preferences form may actually reduce the overall code complexity a bit. I think it would be reasonable to have two entry points.
Users should know which gadgets are active for anons and for other users who never touched their "preferences".
Also, users should know what will be the result of pressing "Restore default settings".
It is possible to know this by reading Mediawiki:gadgets-definition, but this is not good enough.
peace.
------
See also:
* Gadget preferences should indicate required skins. – T65532
* Show defaults of all user preferences, in general for MediaWiki. – T70689
I couldn't find a way to set a gadget to be enabled for users with right1 OR right2.
I want to enable Twinkle for both rollbackers and patrollers. If I use
rights=patrol,rollback
The gadget will be enabled only for users who have both rights simultaneously.
I even tried defining the gadget twice:
* Twinkle[ResourceLoader|rights=rollback|dependencies=mediawiki.util,jquery.ui.dialog,jquery.tipsy]|morebits.js|morebits.css|Twinkle.js
* Twinkle[ResourceLoader|rights=patrol|dependencies=mediawiki.util,jquery.ui.dialog,jquery.tipsy]|morebits.js|morebits.css|Twinkle.js
But only the last definition will be effective. (In the example above, only users with patrol right will see twinkle in their preferences)
It would be helpful if it was possible to define rights using some Boolean operators instead of comma-separated list.
--------------------------
**Version**: unspecified
**Severity**: enhancement
Add ability for section description of gadgets section
The "General gadgets" text in https://test.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&oldid=155819 is not shown on Special:Preferences on Gadgets tab.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://test.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&oldid=155819
I was thinking about creating some QUnit tests for one of my user scripts and also for a gadget, but AFAIK there is no standard way to do this.
The [[Special:JavaScriptTest/qunit]] only says "This function has not been enabled on this wiki." but maybe it should provide a way to let users to run their QUnit tests, e.g. by defining the page name of a script, or some URL param.
For example, if a wiki has some gadgets the users (mainly sysops and gadget editors) could follow links to pages such as
`[[Special:JavaScriptTest/qunit/<some name related to the gadget>]]`
(or use a URL param, as in "Special:JavaScriptTest/qunit?gadget=foo") as soon as a gadget is changed, to ensure the latest changes didn't broke anything.
**See Also**:
* {T71445}
* {T53651}
It would be handy to have at least a button to "disable all" gadgets on [[no:Special:Preferences#mw-prefsection-gadgets]]. Other buttons might be useful as well.
[2023 update]:
Allow "user gadgets" to be defined within user space. Similar to site gadgets, they are ResourceLoader modules consisting of one or more scripts, stylesheets and JSON files. They can specify other RL modules, including other user gadgets, as dependencies.
Users can enable user gadgets written by authors they trust through a GUI in gadgets tab at Special:Preferences.
**Benefits:**
* User gadgets bring in native support in MediaWiki for user scripts which until now were supported rather unofficially via loading in scripts from the personal common.js page
* Provides the benefits of ResourceLoader minimisation and caching for user scripts which as of now is applied only to the common.js page (and not to pages imported from there). T27845 was declined in favour of this one.
* Enables effective use of Codex/Vue.js in which components are separate package files (currently doable only in site gadgets). T334438
* Allows us to extend the feature in future to bring in greater control if necessary, such as by:
* Not allowing unconfirmed users to create gadgets
* Allowing admins to disable an insecure gadget for everyone without deleting the page
* The GUI can be extended to allow specifying per-site CSP opt-ins for external domains accessed by these scripts T208188
**See also**:
* {T29281}
* {T29561}
* {T27845}
* <https://www.mediawiki.org/wiki/User:Krinkle/Gadgets_3.0>
Occasionally someone will enable a new gadget and make it enabled for everyone with the ability for individual users to opt-out. It would be nice if MediaWiki somehow notified the user (when visiting Special:Preferences or via e-mail or in some other way) that a new gadget had been enabled (without the user's consent) and explain to the user how to disable the gadget, should they wish to.
Even a "New!" tag next to newly enabled gadgets might be sufficient. I'm not sure. The current practice of silently changing other users' user preferences seems fairly unacceptable, though.
--------------------------
**Version**: unspecified
**Severity**: enhancement
Screenshot of
See screenshot. It is particularly evident in "Configurable edit buttons (old style)" where the colons are mixed up.
You need to have an account and be logged in to display the Gadget tab in Special:Preferences.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://translatewiki.net/wiki/Special:Preferences?uselang=he#prefsection-gadgets
**Attached**: {F8036}
Tracker and implementation bug for the Gadget Manager that was going to be implemented during the Gadgets 2.0 sprint in July 2011.
This task tracks tasks for the [[https://www.mediawiki.org/wiki/Gadgets_2.0|Gadgets 2.0]] initiative, including any new requirements for ResourceLoader in MediaWiki core.
See also:
* [[https://www.mediawiki.org/wiki/Extension:Gadgets/Roadmap#Gadgets_2.0|mw:Extension:Gadgets/Roadmap#Gadgets 2.0]]
* {T37126}
* {T59891}
* {T1238}
The english wikipedia is already loaded with gadgets. If someone gets really bored, we should see about redesigning that to show the gadgets that a user has enabled + "Add a gadget". The Add button could open something like a searchable gadget directory alla Google (see link).
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://www.google.com/ig/directory?synd=open&source=gghp
It should be possible to have global gadgets, that are available by default on the gadget list of each WMF wiki. This is specially useful for keeping a single central copy of popular gadgets, such as hiding global notices, or HotCat, WikiMiniAtlas, etc.
The possible repositories would be Meta-wiki or MediaWiki.org (see also {T59336}).
This probably depends on {T16950} to be fixed first
**See also**
* [[https://www.mediawiki.org/wiki/Extension:Gadgets/Roadmap|mw:Extension:Gadgets/Roadmap]]
* [[https://meta.wikimedia.org/wiki/Requests_for_comment/Global_bits_and_pieces#Scope|m:Requests for comment/Global bits and pieces#Scope]]
For the standard user the gadgets are just a collection of extra settings. He doesn't / shouldn't bother if its a MediaWiki core feature or a user script (while user script is only half correct since it's still enabled by admin / sysops though). The user instead needs to ask himself whatthe heck Gadgets are and why they are not logically sorted under the other sections but srted into h2 sections on the page (see Wikipedia).
MediaWiki:Gadgets-definition should be able to let you list gadgets into the standard sections or create new sections for it.
E.g. "Make text fields (e.g. the edit form) use a sans-serif font instead of a monospace font." would be better placed in the "Editing" section. Just my feelings. Example set-up of the Gadgets-definition:
```
== Editing ==
* wikEd|wikEd.js
* textareasansserif|textareasansserif.css
== Interface ==
* exlinks|exlinks.js
* purgeTab|purgeTab.js
== Misc ==
== library-gadgets ==
* JSL|JSL.js
```
The checkboxes for wikEd and textareasansserif would be added at the end of the Editing section
Interface would be a new section at the end (but before the standard Misc imo) including the stated two Gadgets.
At the end of the standard Misc section a new h2 would be added with JSL below.
If no "section" was defined in the Gadgets-definition, create "Gadgets" as is handled atm.
Makes sense to me ;)
--------------------------
**Version**: unspecified
**Severity**: enhancement