?withgadget query parameters allows for ad-hoc loading of gadgets
(after passing all other basic checks). This was recently added in
I5b30d4e.
In T29766#7611796 Gergo raised concerns about how this can be
potentially abused.
This patch aims to restrict the feature by giving gadgets latitude
to either use it or not depending on the nature of the gadget.
The patch does so by adding `supportsUrlLoad` option that gadgets
(maybe those deemed safe) can use it to opt-in to the parameter.
By default gadgets don't support it, so it can be enabled for each
on a case-by-case basis.
Bug: T29766
Change-Id: Ie64174085e650579d76cc862774a4fe1b3d08396
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
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
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
When viewing pages, the 'withgadget=' query parameter can be used in
the URL to load a gadget that isn't enabled by the user's preferences.
The gadget is only loaded if all other conditions are still satisfied
(supported skin, supported targets, required user rights).
Bug: T29766
Change-Id: I5b30d4e0010561685eef661a515e2892045bb776
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: Ifaca96e288c475017636c2408712d6a20aa77da9
Without the default the preference is never deleted from the database,
even it was disabled by the user.
Bug: T291748
Change-Id: I1010e260fda118cbea83ad39e33055e403e37630
Multiselect can build by message keys only and allows to parse them.
This reverts fix for T32182, there is no way to handle the dir on each
item/checkbox at the moment
Reintroduce Iccd6202c443bd699aa3a911c8ba36a2b7bcdcfed (reverted by
I1cf3c7c61e9e90567587350639590691add1af34)
Bug: T58633
Bug: T278650
Depends-On: I8f52f21ae2641ddcad1aa85ce6bf14de1a09ab4b
Change-Id: If71008195f58faff9f302f7ea2bf9dbb1a527844
On mediawiki version 1.36 and before, just returning false in this hook can't display error message by default.
Set $status->value manually still to provide backward compatibility.
Bug: T280312
Change-Id: Ic80fd227668794c21299a3f7879f61a20a2f55bd
Multiselect can build by message keys only
This reverts fix for T32182, there is no way to handle the dir on each
item/checkbox at the moment
Bug: T58633
Bug: T278650
Depends-On: Ie983757081dc39f3685ba5b01b02bd124880e1af
Change-Id: Iccd6202c443bd699aa3a911c8ba36a2b7bcdcfed
As a Wikimedia-deployed extension, we don't keep B/C for older MW branches,
instead people should use the release branches.
Change-Id: I8b8e554a8a8663c19ce3ea52f047c8d40537b042
In ApiQueryGadgetCategories.php for function getList() I've added inline comment for ignoring this rule, because is unclear why it throws this error.
Change-Id: I74c4a6c75f48b8f7a237396666db3b37993c300d
The wrapper tags that we have to create when using the 'rawrow' option
would have to be different for OOUI and non-OOUI preferences forms,
making it impossible to support both at the same time.
We used it in order to generate `<td colspan=2>...</td>` rather than
`<td></td><td>...</td>`, and make the description span both the label
and the input columns. However, this is not necessary, because the
label column is entirely hidden on this page of preferences, as all of
the preferences have no labels.
Bug: T203202
Change-Id: Ib9510a8bfb2430fdda3988d88628c9f0c509c6d0
* "raw" and "rawrow" are documented as booleans.
* "raw" does not have any effect if "rawrow" is set.
* "label" does not have any effect if "rawrow" is set.
* "noglobal" refers to GlobalPreferences. It does not have any effect
because "info" fields are blacklisted anyway.
https://github.com/wikimedia/mediawiki-extensions-GlobalPreferences/blob/master/includes/GlobalPreferencesFactory.php#L75
Also see my longer comment in I1ab2bc6 where I explain all these changes.
Change-Id: I7b4e08b45070ae07935e1cd59091b3d608583e5b
The user's preference usually reflects the displayed skin, however this isn't
true if the `useskin` URL query is set, or MobileFrontend is being used.
This fixes gadgets being displayed on the wrong skin when using `useskin`,
and allows mobile-specific gadgets (using `skins=minerva`).
Testing if the gadget is allowed in the current skin is split out from
`isAllowed` to `isSkinSupported` to enable a future patch showing gadgets
on preferences regardless of if they are allowed on the current skin.
Test coverage is added for both functions.
Also fixed another test which wasn't working, presumably because the placeholder
user didn't have the "read" right, so the section wasn't being kept.
Bug: T199478
Change-Id: I21febe92d54d6d0b89925f902581cc2739d824fb
