Adds a "namespaces" option to the gadget definition, which takes a
list of namespace IDs. Enabled gadgets will only load when the
viewed page is in one of the required namespaces.
Bug: T204201
Bug: T63007
Change-Id: I7f797e35352b242ad78704074e98c6569a1adf91
Follows-up 087ab65e24 (Ieae6706537). To avoid silent mistakes such
as during development of T63007 (I7f797e35352b242).
Bug: T303194
Change-Id: If675f8d02ed3fee768af3d2b4912249319ae9ef4
- Always define gadget enable/disable preferences
- Show a gadget's preference when it can be enabled
Bug: T341421
Change-Id: If32eecebccf2c9b557d7dde273b7faf7118a7ac3
The test uses black magic to override the behaviour of
MediaWikiGadgetsDefinitionRepo. However, this magic doesn't work well
with I2ac659a4, which disabled gadget loading in non-database tests.
This test is the only one that needs that code to be run, although it
won't actually make any queries because of said black magic.
Add the test to the Database group as a temporary (TM) workaround to
replacing the TestingAccessWrapper magic with something else.
Change-Id: I7d9fd612dd685a5728d3a7a9ced97fd5ac45f491
TestUser needs a database connection to create the User, but this test
doesn't need a real user, so just use a mock instead.
Ideally we'd use Authority, but the hook still takes a User object.
Change-Id: If6cb7e3756036fc458a4308b06499c4bc0d3d9b0
The ResourceLoader module associated with the gadget will have
mobile and desktop targets, but this allows gadgets to disable
themselves on the mobile site if necessary by not adding the gadget
to the page if it's been marked as such.
This also has the benefit of not showing the gadget on the preferences
page if it's not relevant.
Bug: T328610
Change-Id: I4f2b57d1d22f641ff7520358a46cd0e6b2103aa9
Cache array representation of the Gadget object instead of the
php-serialized representation. Gadget::toArray() is an inverse of the
constructor which already constructs an object from an array of config
values.
Also, the static Gadget::newFromDefinitionContent method which accesses
the service container is replaced with the dependency-less
serializeDefinition() method.
Bug: T303194
Change-Id: Ieae6706537143d766777b2299c31726e2a1dfd29
Gadgets can mark themselves as ES6-only by specifying the requiresES6
boolean attribute. Syntax validation is disabled for them (as the
validator doesn't support ES6 yet), and they are loaded together in a
separate request.
The minifier doesn't reject syntax errors, and thus these would
be passed through to web clients. Hence, communities using this feature
are encouraged to use ESLint or another linter to make sure only
valid ES <= 6 code is being used.
Because of the above, this feature is only made available for
non-default gadgets.
Bug: T75714
Change-Id: Ib98ac0700471554d5721d7ab858d4660e1e0e980
* Remove most APCu logic, including the reverse checking of WANCache
touch time to validate the APCu key
The APCu expiry had a 7-15s blind TTL before this check took place.
Keep the conservative part of this (blind TTL). This should be
more than enough to debounce memcached traffic.
* Simplify WAN handling with plain key and delete (using the default
holdoff tombstone, which should take care of edge cases like second
DC warming up the WAN key shortly after a delete).
* Fix incorrect method doc about being by section. The returned
list is not by section.
Change-Id: If14ff83a29367df58d1824615bcf0bcd2edc886f
Locally these tests are failing for me on master every time.
In WMF CI, it seems they are passing right now, although they
too would start failing as of Ib27fd34fbfe7a7. My guess is that
my change there causes the service container to be initialised
earlier and thus causes the modified global to no longer be seen.
At the very least this should have been using setMwGlobals(), which
would have also avoided the issue by ensuring a service reset,
however use setGroupPermissions() since it's tailor made for this
purpose, and avoids potential problems later with default groups
not existing.
Change-Id: I8f02ffc996d6077ca6e7433229b1ea5d8fc6ce7c
?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
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
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
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
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
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: I5fa8001a2ea7fdab2dbf9ce8cba9d1764f7a4562
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
This is more an integration test than anything. The @covers tags I found
are to strict, in my opinion. These test cases cover more code.
Change-Id: I6cef7ce0c612ac3dfbb855c495032df1fe96f4af
… as well as update a line of documentation I had stashed. I think this
does not need it's own patch, or does it?
Change-Id: I99eee1f7b5ec96c1c75e73d66200bc41807452fa
Follows-up 152484566, which added support for it in Gadgets 2.0, but
it's easy enough to make it work in existing definitions as well.
That way, people can stop using 'rights=hidden' hacks.
Bug: T33150
Change-Id: Idd6944a9ad38279e117c1a02a4b5fd0343455ba0
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
