Page MenuHomePhabricator
Search Advanced Search
    • Task
    **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.
    • Task
    `[322769faea345c08bf13fac0] /index.php/Special:ChangeContentModel/Gadget_definition:Foobar Exception: Tried to save non-GadgetDefinitionContent to Gadget definition:Foobar` Deliberately being thrown in GadgetHooks::onEditFilterMergedContent (though with `// this should not be possible?` comment which indicates invocation via ChangeContentModel may have been overlooked).
    • Task
    Now that T198758 has been implemented, admins are able to edit gadget json pages, with MediaWikiGadgetDefinitionRepo. However, GadgetDefinitionNamespaceRepo uses a single `gadgets-edit` right for all files in the namespace. Ideally, there should be a different user right for json, so that it can be given to admins rather than just interface-admins.
    • Task
    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`
    • Task
    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/) 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.
    • Task
    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.
    • Task
    **Feature summary** (what you would like to be able to do and where): Make it possible to embed gadget options in other panes of Special:Preferences than the gadgets pane. This would be a setting in the gadgets definition page for the wiki. This task does not propose to be able to list a gadget under multiple panes, just a single pane other than Gadgets. **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 are poorly integrated with the rest of the preference tabs. The pane specific to gadgets turns quickly into a hopefully organized but usually fairly flat list of gadgets that are easy to get lost in (humans like to think hierarchically). The headings on that pane often duplicate the other panes in special:preferences. **Benefits** (why should this be implemented?): Discoverability of gadgets improves and we stop duplicating the other panes, which leads to better use of that specific gadgets pane as "it doesn't fit elsewhere" or possibly even "here are some ones with different groupings than provided in other preference panes". Why this may be should not be implemented: Gadgets are community-created rather than scrutinized via code review etc. etc. which may (but hopefully don't) carry with them associated security risks, etc. etc., which may not be the implications carried on the currently non-gadget panes. I think this can be overcome with the usual disclaimer and some sort of section heading on the specific panes e.g. "Gadgets"
    • Task
    In the long run, WVUI should be a great replacement for OOUI in gadgets for making simple and easily-reused code. A demonstration workflow for setting up a "Hello World" script would be a good first step to starting to introduce it. I imagine such a script would simply pop up the most basic dialog (once it exists as a component) and allow to dismiss, thus keeping the focus on how to set up WVUI for the gadget environment as opposed to actually using WVUI's features/components (for which the documentation would presumably be the same as using WVUI in core JS?)
    • Task
    Please translate these namespaces Определение гаджета → Гаджет билгаляккхар Обсуждение гаджета → Гаджет дийцаре Обсуждение определения гаджета → Гаджет билгалякхарах дийцаре. https://ce.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8:%D0%A4%D0%BE%D1%80%D1%83%D0%BC#Namespace
    • Task
    [[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
    • Task
    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
    • Task
    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.
    • Task
    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]].
    • Task
    (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', ]; ```
    • Task
    (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', ]; ```
    • Task
    (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', ]; ```
    • Task
    Since the startup payload varies by skin, the Gadgets extension should take advantage of this by not registering gadgets that are only enabled in certain skins.
    • Task
    (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', ]; ```
    • Task
    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', ]; ```
    • Task
    Can the gadgets-definition-edit and gadgets-edit permissions be added to the stewards and interface administrators groups for WMF projects? While this isn't really live yet, edge cases have arisen that currently require contacting WMF staff (the only group with this access) to make adjustments. See example: https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&oldid=909187898#Add_maintenance_template from enwiki
    • Task
    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).
    • Task
    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.
    • Task
    **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.
    • Task
    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?
    • Task
    Please find some suggestions below. * The current concept of ##rights## and ##skins## and target etc. shall be extended. * The aim is similar to T63007 and perhaps in other places. * However, the syntax is extended within the current style. * Packaging shall be based on properties which can be evaluated immediately on loading. * The target is to avoid loading of meaningless modules, therefore each rule is further limiting the scope of gadgets required within the current page under current conditions. * In cache some more module packages will be founded per site, but repeating the same aggregation. * The rules still follow a simple AND combination. Some might wish an entire boolean language, but no implementation expected within this century. == Separators == Currently comma separation only is expected for multi-value. * Introduce space separator as regular syntax as well. * Keywords are simple ASCII words with no space inside, dependencies with dot, sometimes hyphen. * Tokenization is rather easy then, and quite usual. * Trimming between equal sign and pipe is no big deal. * Comma+space should not disturb anywhere. * Even {key Tab} may be used instead of space, or any whitespace. That would improve readability. == Boolean considerations == * If one //keyword=// rule is given, multiple items open an OR choice if not excluding. * All rules need to be matched, they form an AND expression. * A //keyword=// rule may occur multiple times (with other items). That is an AND junction of their items. * If items are prefixed with ##-## this is an exclusion rule and all exclusions are to be met. == Namespace == Syntax: namespaces= Value is separated list of namespace numbers. * If element starting with ##-## that might be exclusion rule. //Example:// |namespaces=14| Load on category pages only. Otherwise the gadget will always start, first check namespace, abort immediately on most pages. == Special pages == Syntax: specials= Value is separated list of special page name keywords, case insensitive. * Keyword could be ##specialpages## if desired, but only one of them. //Example:// |specials=Recentchanges,Watchlist,EditWatchlist| == Action == Syntax: actions= Value is separated list of ##&action=## keywords. * ##edit## shall cover ##submit## as well. * If editing is not permitted to this user, ##view## might be required and ##edit## is bounced back (no editing tools meaningful). * If element starting with ##-## that might be exclusion rule. * Some special pages are rewriting themselves into ##action=##, e.g. ##Diff##. That needs to be considered. It depends on the moment when the current situation is resolved. //Example:// |actions=view,edit,parsermigration-edit| Do not load on ##history## or ##info##. == Content model == Syntax: contentmodels= Value is separated list of case insensitive content model names. //Example:// |contentmodels=css| Run linter etc. on appropriate language only. Or limit to ##wikitext## editing. == Page properties == Syntax: pageprops= Value is separated list of case insensitive pageprop names. * If element starting with ##-## that might be exclusion rule (AND NOT). //Example:// |pageprops=templatedata| |pageprops= -disambiguation -wikibase_item| * If TemplateData is present on this page, then link some keywords and add nice formatting. * If this article is not linked to WikiData and it is no disambiguation page then remind to look for WikiData item or create one if topic is appropriate. == Transcluded page == Syntax: transcludes= Value is whitespace separated list of page names with underscore ##_## rather than space. * If element starting with ##-## that might be exclusion rule (AND NOT). //Example:// |transcludes=Template:citation_needed| If that template is transcluded, load a gadget to find reliable sources. == Category == Syntax: categories= Value is whitespace separated list of category titles (no leading namspace ##Category:##), with underscore ##_## rather than space. * If element starting with ##-## that might be exclusion rule (AND NOT). Alternative approach to ##transcludes=## rule. //Example:// |categories=Wikipedia:Gadgets/Talk_utilities| If current page is within that category, load a gadget to support discussions. Multiple templates might trigger such hidden category. == User groups == Syntax: groups= Value is separated list of case insensitive user group names. * If element starting with ##-## that might be exclusion rule (AND NOT). * ##all## is not required but basic set anyway. Members may be subtracted. //Examples:// |groups=sysop| |groups=-user| |groups=user -sysop| The second one is matching anonymous users. The third one are registered accounts, but might be not too experienced and powerful. == User language == Syntax: userlangs= Value is separated list of case insensitive language codes. * If element starting with ##-## that might be exclusion rule (AND NOT). * Current user language ##pt-BR## shall match ##|userlangs=pt|##. //Example:// |userlangs=en-US,fr,zh-Hant,simple| Shall exploit right-to-left scripting, translation helpers, special letter support, spellchecking etc. == Content language == Syntax: contentlangs= Same as ##userlangs## but for page content language.
    • Task
    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.
    • Task
    **Motivation** Special pages are super useful for all kinds of analysis and research. For example, - [[https://en.wikipedia.org/w/index.php?title=Special:ListUsers|Special:ListUsers]]: How many users have a specific user access level (per Wikipedia)? - [[https://en.wikipedia.org/wiki/Special:ListFiles|Special:ListFiles]]: How many local files does a wiki have? - [[https://en.wikipedia.org/wiki/Special:WhatLinksHere|Special:WhatLinksHere]]: How many pages link to a specific page? **Problem** These pages don’t show how many list entries there are. So in order to obtain this number, all list entries need to be copied from the special page into a spreadsheet. This is cumbersome work, especially when the list entries are stretching across multiple pages, that can probably be avoided. **Wish** Display the number of the list entries on each special page with lists, as this is done with the results on search pages. {F23718376}
    • Task
    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.
    • Task
    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
    • Task
    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.
    • Task
    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}
    • Task
    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"?
    • Task
    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.
    • Task
    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.
    • Task
    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).
    • Task
    >>! 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 ?
    • Task
    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.
    • Task
    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}
    • Task
    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.
    • Task
    This is in relation to the RL2 (Gadgets 2.0) development branch. what exists? are they up to date? do they cover the new classes/code/etc.? do they all pass? Especially make sure there are adequate tests for the new GadgetManager. Outcome of this card will be another task to create missing tests and update out-of-date tests.
    • Task
    * 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
    • Task
    On (backend) page request on enwiki, 'enwiki:gadgets-definition:7' is fetched from memcached. It's 53k of data. That is excessive.
    • Task
    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}
    • Task
    >>! 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. >
    • Task
    Gadgets, when enabled by a user, load on all pages in all namespaces. This doesn't cause any immediate functional problems, but is inefficient. In some cases, very unacceptably inefficient, to the point that a gadget may be removed from a wiki or disabled due to performance problems. This is usually worked around in one of two ways: 1. The gadget is split into two parts. A part that contains the actual gadget itself (hidden, disabled by default). And a (tiny) **second** part that is loaded always and checks whether the current page is the "right" one, and then loads the other. * Downside: Two definitions instead of one. * Downside: The page will first load without the gadget, and then later the gadget gets loaded (typically between 1-10s seconds later, depending on the connection and bandwidth). 1. The gadget is made hidden and is instead loaded by url parameter (e.g. `/wiki/Example?withModule=ext.gadget.foo`). * Downside: Cannot be enabled on a per-user base (url parameter applies to all users). It also means the gadget only loads when the user follows a specific link, e.g. not when visiting the page through other means. * Downside: The page will first load without the gadget, and then later the gadget We should instead add an option directly in the Gadgets extension to specify when a gadget should load (by default still everywhere). Eg. based on the namespace, or page title, or page action, or canonical special page name. -------------------------- Original request: > > **Author:** `gryllida` > > **Description:** > We should add an option to specify what pages a gadget is active on. Many probably just do this manually, but it looks reasonable as some gadgets would only be useful for contributors' talk pages for example. This could be a namespace name, or sometimes even a glob mask (Wikipedia talk:Articles for Creation/*). **See Also**: * {T8883} * {T31028} * {T17075} * {T241524} * {T204201}
    • Task
    When working with gadgets, one needs to have both Special:Gadgets and MediaWiki:Gadgets-definition open because Special:Gadgets contains useful links, but not gadgets' dependencies which are shown on MediaWiki:Gadgets-definition. Displaying dependencies on Special:Gadgets would solve this problem.
    • Task
    Currently just fetching user options on Commons is slow due to a slow template in the gadget descriptions section. This actually causes deadlocks in ApiOptions when the watchlist token has to be created, the slow parsing happens, and then the actual preferences update happens. This is all pointless, since the API doesn't need those checkbox labels anyway... One can profile this using eval.php on commons using: Profiler::setInstance( new ProfilerSimpleText( array() ) ); Profiler::instance()->setTemplated( true ); $preferences = array(); var_dump( GadgetHooks::getPreferences( $wgUser, $preferences ) ); wfLogProfilingData(); -------------------------- **Version**: 1.23.0 **Severity**: normal
    • Task
    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.
    • Task
    [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
    • Task
    A working version of the filtering box (loading might need refactoring) It's already a problem that there are to many gadgets to quickly locate the ones you want. Sections help but they are not very strict and meaningful. Also more gadgets for even small stuff could be added be then user would never find them... We (on pl.wiki) even had a questionnaire to remove the least used gadgets. So. I think a simple filter input would help solve this issues. I'm attaching an add-on script that allows filtering as the user types leaving sections in place. User can filter by any part of a word in description and even by two parts of a word in any order ("nav po" should find Navigation popups). I've tested this on English and Polish Wikipedia so hopefully it should work without problems, but you might want to put GadgetFilter.init() in some more appropriate place. -------------------------- **Version**: unspecified **Severity**: enhancement **Attached**: {F11020}
    • Task
    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.
    • Task
    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
    • Task
    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
    • Task
    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
    • Task
    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}
    • Task
    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.
    • Task
    From @Nux's comment on T29488#313444 >I've submitted this bug (T29488) with specific needs in mind. There is no way I know to: > 1. Load user scripts in the header to allow actually running their code BEFORE the page starts to render (needed to inject CSS or faster adding of crucial elements). > 2. Load user scripts in order (without the need of contacting administrators). I'm not sure, but I think this probably means we need to provide a way to set `position = top` on user scripts. Maybe it is related to the need of creating modules from wikipages, maybe not. **See also**: * {T29281} * {T29561} * {T27845} * <https://www.mediawiki.org/wiki/User:Krinkle/Gadgets_3.0>
    • Task
    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
    • Task
    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}
    • Task
    Tracker and implementation bug for the Gadget Manager that was going to be implemented during the Gadgets 2.0 sprint in July 2011.
    • Task
    This task tracks tasks that will be resolved by [[https://www.mediawiki.org/wiki/Gadgets_2.0|Gadgets 2.0]], including any required ResourceLoader issues. **See Also**: * [[https://www.mediawiki.org/wiki/Extension:Gadgets/Roadmap#Gadgets_2.0|mw:Extension:Gadgets/Roadmap#Gadgets 2.0]] * {T37126} * {T59891} * {T1238}
    • Task
    Inspired by the "withJS-url parameter"-script floating around various wikis (which calls importScript() if the passed pagename is in the MediaWiki:-namespace), I think such functionality would qualify as core functionality. For backwards compatiblity and to avoid any security issues on wikis which use the MediaWiki:-namespace on a less-than-sysop security level, this should be disabled by default, and enableable with a wiki global (eg. $wgAllowWithModuleLoading=true;) However given how the resourceloader currently works and how it will/may work in the future [1]. I think it's best not to implemenent the script as it is now on those wikis, instead I've made this bug depend on bug 27535 ( registering wikistyles and wikiscripts as part of a module ), and propose to make the parameter someting like withModule. Example: * http://example.org/w/index.php?title=Foobar&withModule=ext.gadget.Foobar That way it can be used to load CSS as well, since CSS can be (part of) a module. This also stops the need to create mini-scriptpages in the MediaWiki:-namespace that would call importScript() and importStylesheet() several times (once for every css/js part of the module) in order to make it work with the withJS-hack.
    • Task
    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
    • Task
    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]]
    • Task
    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