This hook needs the old call structur as there is not a interface for
it.
When CodeEditor extension is changed to provide that interface, this
needs to be moved to another class, because the extension is optional
and the interface not loaded on all installs.
This change is a follow-up to b504a6f496
and reverts the change for hook CodeEditorGetPageLanguage because
onCodeEditorGetPageLanguage is still a static function.
Bug: T271014
Change-Id: I0ac6f353be099c4c9b4cb36b65cb463b7b7b89ea
== 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
HTMLForm would handle title itself, don't need to set it manually here.
Depends-On: Iaec81a2fb49162f2fc764f143f88e887572a3a0b
Change-Id: I4a9788e853463e51570ba7c04a8bd40f1ed95cfa
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
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
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
This change raises MediaWiki version requirement to 1.32.
Change-Id: Ieffed829bf5a8e1f138fd5f63518e415cebb1287
Depends-On: I193f5b9a95430b0a05573c361715e053e5411e32
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: I94d4d2b21bdbbc12e1a34c1373a631e03ac2df93
Currently takes >24 hours to complete on enwiki and thus isn't run
at all. Need a better optimised query. Until that happens, we can
turn it off on enwiki.
Bug: T121484
Change-Id: Idcf2a8a1cdf5ce4c2f6a631ef980be5a48ca547b
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
Register the "Gadget", "Gadget definition", and their respective talk
namespaces. It will not be possible to create any pages in the Gadget
and Gadget definition namespaces due to the "gadgets-edit" and "gadgets-
definition-edit" rights not being granted to any groups.
Depends on Iaf8b44d02adf9 in MediaWiki core.
Change-Id: Ia88c774cc0decc252a4a4277d14822048db95801
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
* APC will be used if around as a tier 1 cache
* This also makes it easier to have mixed zend/hhvm servers
Bug: T106743
Change-Id: Ie9f234753f78215441474dddc4eadedbd2b76ad7
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
Add a configuration option, 'GadgetsCacheType', which may be used to specify
the ObjectCache type to use for gadget definitions.
Change-Id: I1e02f7b6c470c5fffa014c6247c71f43a69420b6
