In addition, renamed several instance of $output to $parserOutput to
help readers (and code search!) differentiate between variables which
contain a ParserOutput and those which contain an OutputPage (esp.
since those two classes contain many similarly-named methods).
Bug: T296123
Change-Id: If34330acf97d2c4e357b693b086264a718738fb1
* Gadget::isEnabled() only requires a UserIdentity, not the whole User
* Gadget::isAllowed() only requires an Authority, not the whole User
Both of those interfaces are implemented by the User class, so this is
compatible with all existing code, and it's easier to call from code
that only has access to a UserIdentity/Authority.
Change-Id: I8ea710c555f6fb7790ae575bb60aab1a05e288d8
Currently, trying to change content model of a page in gadget definition namespace (via either the special page or the API) raises an exception. This uncaught exception has been replaced with a localisable error message.
Bug: T299303
Change-Id: Iad7d353d03cdfb52bf66aa2c9a12bc71a840577c
Hidden gadgets do not have associated user preferences. Adding them to $defaultOptions only causes them to be unnecessarily exported in mw.user.options.
Bug: T299071
Change-Id: Ic55e7f2a9daa405cddd0189de3d32f5825bc336a
Links the following entries in gadget definitions to the associated page:
- scripts
- styles
- datas
- peers
- dependencies (only when they are also a gadget)
- category (links to MW message page)
- messages
unserialize(serialize()) hack is a bit ugly, but it works.
Co-Authored-By: Siddharth VP <siddharthvp@gmail.com>
Bug: T298844
Change-Id: I9154f600997fe693410e7560ed30732102b806aa
When using the Gadget definition: namespace, link to the definition
pages from Special:Gadgets. Also change the wording of the links
to edit the names of the gadgets, to disambiguate them.
Change-Id: I327a4cfa9846edec60e1aaafc674cd66f4e0beae
Allow specifying page actions ('view', 'edit', 'history', etc) in
gadget definitions. If specified, the gadget is run only on the given
page action(s).
This is especially useful for default gadgets like RefToolbar[1] and
TextReactions[2] that only need to be loaded while editing.
[1]: https://en.wikipedia.org/wiki/WP:RefToolbar
[2]: https://en.wikipedia.org/wiki/WP:Text_reactions
Bug: T204201
Bug: T63007
Change-Id: Idde71b3f1f6c36cd21539a2312be8f12217a9acc
The parsed content of JSON files in the gadget is made available from the
gadget's JS files via require(). That is, MediaWiki:Gadget-data.json (or
Gadget:data.json) is available as `require('./data.json')`. This is
supported for both MediaWikiGadgetsDefinitionRepo and
GadgetDefinitionNamespaceRepo. The JSON parsing is done server-side.
JSON can only be used in "package" gadgets - in which the JS files can
also be invoked via require().
Also added a test for GadgetResourceLoaderModule.
Bug: T198758
Depends-On: Ib4556d09c4d393269e32771aab00f59a5f630e1b
Depends-On: Id4589a597ccfc4266b3e63d10f75b146aa7a287a
Change-Id: I21acb46cdd244a39b5cc6963aa763f0113bd1e38
Remove using of User:getOption since this method
will be hard-deprecated. Now it is soft-deprecated.
Bug: T296083
Change-Id: I140cbd5655ac4ae0ad7b6d30c5e6bae0008aba07
Previously attempted in 82281d82d0,
reverted in 7c4ac597e2.
This gives each section and each gadget's entry an `id` attribute,
which can be used for linking, as requested in T126962. Existing user
options still match the new preferences.
It also probably makes future improvements easier. No one understands
multiselects with subsections.
Bug: T126962
Change-Id: Ie96fd94c994d05ab8507920fa560c7ed9c1f9b69
