* 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
== Motivation ==
On a local dev wiki and in CI, where no gadgets are defined yet,
fetchStructuredList() is called on every load.php request and doing
uncached database look ups. This is because T39228 (stale cache
after Gadgets-definition was empty or created) was fixed by disabling
the cache until the page exists. This seems like a poor solution,
and commit I3092bcb162d032 recognises that the problem was not
understood at the time. I propose to instead cache it always and
purge it when the page is modified in any way.
Cold calling fetchStructuredList() accounted for ~170ms of ~400ms
when trying out debug v2 (T85805), thus making it significantly
slower and causing a chain of dozens of requests to pile up.
== Previously ==
* Legacy repo (MediaWikiGadgetsDefinitionRepo) only implemented
handlePageUpdate.
* handlePageUpdate was called from onPageSaveComplete for both
any page edit, and for creations in the experimental namespace.
* The experimental GadgetDefinitionNamespaceRepo is based on
ContentHandler rather than global hooks. This system does not
have a create-specific callback. It called update for edit/create,
and delete for delete. The experimental repo relied on create being
called from the global hook for the legacy repo, and update was
then called twice.
* There was no global hook for onPageDeleteComplete, thus the
legacy repo did not get purges.
== Changes ==
* Add onPageDeleteComplete hook to fix purges after deletion,
with the legacy repo now implementing handlePageDeletion() and doing
the same as handlePageUpdate().
* Fix handlePageUpdate() docs to reflect that it covers page create,
since onPageSaveComplete() called it either way.
* Fix experimental repo to include its namespace purge in
its handlePageUpdate() method.
* Get rid of now-redundant handlePageCreation().
* Get rid of handlePageDeletion() since its implementations would
now be identical to handlePageUpdate().
All these hooks and handle*() methods are just for a memc key
holding gadget metadata. We don't need to microoptimise this
on a per-page basis. Gadget edits are rare enough that purging them
as a whole each time is fine. We do the same in MediaWiki core
with ResourceLoaderGadgetsModule already.
Bug: T85805
Change-Id: Ib27fd34fbfe7a75c851602c8a93a2e3e1f2c38a0
?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
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
Argument 1 ($min) is 7000000.0 but \mt_rand() takes int
Argument 2 ($max) is 15000000.0 but \mt_rand() takes int
Bug: T235049
Change-Id: I2d7d0d6defd312dbed0de833678f3768fa3d7a46
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
… 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
This avoids purge problems due to layered caching. The message cache
is known to take a while to regenerate and uses lockTSE=300.
Bug: T157210
Change-Id: I418e160ddb61c4d3654780f5d2bbb14bc2827e2a
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
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
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
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
