Depending on GadgetRepo::singleton() to return a specific implementation
is fragile. Pass each created/updated/deleted page to
GadgetRepo::handlePageCreation/Update/Deletion() and let each specific
implementation deal with it.
Use LinkTarget to be TitleValue compatible for the future.
Change-Id: Ibe2e26d12369a897c53757adf621926f62af7f7b
Ref discussion on T42284.
Test plan:
* Create gadget A with a .css file only. (Maybe mark as 'hidden')
* Create gadget B with .js file, and peers=A.
* Verify that enabling B will result in B being loaded as general module,
and A being loaded as page style module.
Change-Id: Ib6207e72c576ff387ecdba685a063bdfbb828199
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
Implements:
* Gadget definition content and content handler
* Basic validation for gadget definition content
* GadgetDefinitionNamespace implementation of GadgetRepo
* DataUpdates upon editing/deletion of Gadget definition pages
* EditFilterMerged hook for improved error messages
* 'GadgetsRepoClass' option to switch GadgetRepo implementation used
* Lazy-load the GadgetResourceLoaderModule class so we don't need to
load each individual gadget object unless its needed
Note that Special:Gadgets's export feature intentionally doesn't work
yet, and will be fixed in a follow up patch.
Bug: T106177
Change-Id: Ib11db5fb0f7b46793bfa956cf1367f1dc1059b1c
In the backend, allow:
* Adding dependencies on messages
* Marking gadgets as hidden so they don't show in preferences
These cannot be used by MediaWiki:Gadgets-definition gadgets, but will
be used by Gadgets 2.0 gadgets.
Change-Id: I55e97de9d631ae001ccc0164db172ba9c5689a34
The time has come to stop supporting legacy gadgets that haven't
migrated to ResourceLoader yet.
For many Gadgets, migrating to ResourceLoader will be as easy
as adding "[ResourceLoader]" to its definition on MediaWiki:Gadgets-definition.
However for older gadgets, they may need more maintenance. Though
similarly they may've already been malfunctioning silently.
The most common techniques used by legacy scripts, and what their
equivalents are in modern JavaScript, see:
<https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)>
Ref T107399.
Change-Id: Ia5f7323a40a28541515ef3a3f5079f1cc940f392
GadgetRepo is an abstract class based off of the implementation in the
RL2 branch.
It is a singleton that provides basic methods to construct and interact
with Gadget objects.
The MediaWikiGadgetsDefinition class is an implementation of GadgetsRepo
that parses the "MediaWiki:Gadgets-definition" page for gadget
definitions.
Tests were left in place to demonstrate that no functional changes have
been made aside from relocation of code. Some tests should be moved to
separate files in the future.
Bug: T106176
Change-Id: I3e802889f6f495783f4dbac65c2a8cefa824a778
Follows-up 192d37b19a.
So we can turn them off in preparation of Gadgets 2.0, which
doesn't support them at all.
Change-Id: I98b4146579ccbbfcad8b83a51cc095da1fad673c
* Bumped the key version due to key wrapping
* Removed isValidList() gived the key versioning
* Follow up ba1311c323 by making APC viable;
previously, definition purges would not work
Bug: T93141
Change-Id: I6da3eede044bf4b840b3f9656a1ae8105941dc6b
