Help:Gadget

From the AARoads Wiki: Read about the road before you go
Jump to navigation Jump to search
AARoads Wiki data structure
Namespaces
Subject namespaces Talk namespaces
0 (Main/Article) Talk 1
2 User User talk 3
4 AARoads AARoads talk 5
6 File File talk 7
8 MediaWiki MediaWiki talk 9
10 Template Template talk 11
12 Help Help talk 13
14 Category Category talk 15
100 Annex Annex talk 101
828 Module Module talk 829
Deprecated
2300 Gadget Gadget talk 2301
2302 Gadget definition Gadget definition talk 2303
Virtual namespaces
-1 Special
-2 Media
Current list (API call)

A Wikipedia gadget is a JavaScript program and/or a CSS snippet that can be enabled simply by checking an option in your preferences. The gadget's function is provided by the MediaWiki extension Gadgets.

General criteria for gadgets

In order to be deployed on the English language Wikipedia, gadgets should generally pass the following conditions:

  1. Gadgets must work if just included with no further configuration. They can be configurable via personal common.js, but must work unconfigured.
  2. Gadgets must be compatible with all major browsers, i.e., they must not terminate with errors.
  3. Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.
  4. Duplication of gadgets should only be made if it is reasonable.
  5. Collections of scripts should be split if they have disparate functions.
  6. Gadgets requiring permissions must be marked and must fail gracefully if the permissions aren't present.
  7. Gadgets only working in some skins must be marked as such if that data is available.

Gadgets that are marked as default and load for large groups of users have additional criteria they need to conform to.

Proposals

New gadgets should be proposed at The Interchange.

Installation

Gadgets can be installed after discussion at the technical section of the village pump by interface administrators in the following way:

  1. Add the header below and the script code to MediaWiki:Gadget-scriptname.js
  2. Optionally, add the header below and CSS code to MediaWiki:Gadget-scriptname.css
  3. Add a script description to MediaWiki:Gadget-scriptname. Please link to the script home and/or help page and state browser requirements if needed.
  4. Add to MediaWiki:Gadgets-definition under the appropriate heading
     * scriptname|scriptname.js[|scriptname.css|otherscript.js|...]
    

The gadget should now appear on Special:Gadgets.

Comments

Comments or warnings can be added to the gadget description templates in two ways:

  • noinclude tag (visible on description page with links): <noinclude> comment </noinclude>
  • HTML comments (visible in source text only): <!-- comment -->

Comments added in this way will be automatically discarded during the page creation process.

Header

The following header is to be added to the gadget files:

/*  _____________________________________________________________________________
 * |                                                                             |
 * |                    === WARNING: GLOBAL GADGET FILE ===                      |
 * |                  Changes to this page affect many users.                    |
 * |         Please discuss changes on the talk page before editing.             |
 * |_____________________________________________________________________________|
 * 
 * Imported from version XXXX as of DATE from [[w:SCRIPT_SOURCE|SCRIPT_SOURCE]]
 * SHORT_DESCRIPTION, see [[w:SCRIPT_HOME_PAGE|SCRIPT_HOME_PAGE]]
 */

Default gadgets

A gadget with default keyword is enabled for all Wikipedia visitors and only registered users can disable it. A gadget with [default|rights=minoredit] description would be automatically enabled only for registered users.

Criteria

Gadgets that are enabled by default for all users have to comply with stricter rules. These are essentially the same rules that apply to all default shipped code. This is because users have no active choice in them being enabled and the gadgets can impact the performance, security and stability of the entire website. These gadgets should:

  • Have been reviewed by an experienced JavaScript developer (generally an interface admin).
  • Be "well maintained".
  • Conform with the Third-party resources policy.
  • Be written to run efficiently, i.e. with as little code as required. If full functionality of the gadget requires a lot of JavaScript code, then this code should be loaded conditionally and lazily, or only on demand (click to load).
  • Cause no accessibility problems.
  • Not be required for content to be readable, except for styles-only gadgets.
  • Not interfere with printing pages.
  • Comply with the current security and privacy standards.

This list should not be considered exhaustive.

Template gadgets

Template gadgets are a special category of default gadgets. These gadgets only run on pages in explicit trigger categories, generally controlled by adding a template to a page. Trigger categories should be move-protected as they are integrated with the definition.

Currently installed gadgets

Users can browse a list of all available gadgets in the gadgets section of their preferences page:

Preferences → Gadgets

See Special:Gadgets for a list of all active gadgets and links to their script files.

Pros and cons of changing a user script to a gadget

Pros

  • Adds the script to Special:Preferences, which makes installing it much easier.
  • Adds the script to Special:Preferences, which will help with marketing the script and boost install counts over time.
  • Gives the user script to the community, making interface administrators more likely to grant edit requests from other users, reducing the need to fork the user script if the maintainer goes inactive.
  • Ability to mark it as a "default gadget", which will load for everyone.
  • The ResourceLoader modules and CSS the script depends on load on page load, allowing the script to be ready faster.

Especially once a user script has a lot of users...

  • Gadgets provide minification and bundling with other gadgets, which reduces file sizes and HTTP traffic.
  • Possible protection against hacking. Interface administrators all have two factor authentication, and are removed if they become inactive. A regular maintainer might go inactive then have their account compromised at a later date.
  • Possible protection against a rogue user script developer.

Cons

  • Allows use of JavaScript features upto ES7 only. A few ES8 features like async–await can be used with the requiresES6 flag.
  • If the maintainer is not an interface administrator, they will now need to make {{Edit interface-protected}} requests in order to make any code changes, slowing down development.
  • Lots of steps. Need to make sure the maintainer is OK with it, get consensus at The Interchange, then get an interface administrator to set everything up. May need a plan to switch everyone over from the old user script to the gadget. If there is any concern about bugs, may need to do a staggered rollout.

See also