== What ==
* Remove the empty Gadget and Gadget_definition namespaces.
* Remove the "gadgets-definition-edit" user right.
* Remove need for custom namespace permissions that previously
had to extend editsitejs to apply to NS_GADGET.
== Why ==
Simplify the (unused) "GadgetDefinitionNamespaceRepo" backend for
Gadgets 2.0 by making it less radically different from the status quo.
The experimental 2.0 branch will now make use of the "gadget definition"
content model via "MediaWiki:Gadgets/<id>.json" pages, instead of
through a dedicated namespace.
When I first worked the Gadgets 2.0 branch, content models
were not a thing in MediaWiki, and interface-admin wasn't a thing yet
either. Now that we have per-page permissions and per-page content
models, we don't really need a separate namespace.
This follows the principle of least surprise, and fits well with other
interface admin and site configuration tools such as:
- Citoid, MediaWiki:Citoid-template-type-map.json,
- VisualEditor, MediaWiki:Visualeditor-template-tools-definition.json,
- AbuseFilter, MediaWiki:BlockedExternalDomains.json,
- the upcoming "Community Config" initiative.
If/when we develop the SpecialPage GUI for editing gadget definitions,
this can save its data to these pages the same as it would in
any other namespace. Similar to how Special:BlockedExternalDomains
operates on MediaWiki:BlockedExternalDomains.json.
See also bf1d6b3e93 (I6ffd5e9467), which recently removed the
gadgets-edit user right in favour of the editsite{css,js,json} rights.
Change-Id: I5b04ab251552e839087d0a8a6923d205adc7f771
This already returns safe Message objects, which allow Special:Gadgets
to localise it accordingly.
Avoid formatting the list ahead of time with a hardcoded user language,
and instead use Message::listParam() so that the caller controls
the Language object. This makes it safe to use in jobs, CLI, tests,
load.php and elsewhere instead of previously where RequestContext would
cause an exception or use something the caller doesn't control.
Bug: T298334
Change-Id: I77dd3c7fef86b4c8c41837bfb276b019f30baeb0
Follows-up 3e871f2015 (If45856c563), which was meant to make
change Ie309e761f8b20640f7c0 in MediaWiki core pass, but didn't, and
I failed to realize this before the change landed.
The current error message is quite generic, and does not mention
"quux". The new validator (Peast) gives a better error message, and
thus would contain the word quux:
> Parse error: Unexpected: quux on line 1
My previous change was loosely checking this as a proxy for whether
the source code is included (valid) or stripped (invalid), but this
was a poor proxy. I did that because I assumed, incorrectly, that
this code would become minified. Since that's not true, we can simply
assert the code in its entirety for the valid case, and for the
invalid case only check for the presence of a warning, and leave it to
core to be responsible for omitting the invalid code in that case.
Change-Id: If3b2b4a75013baeaa0d9b92cd10dfb06e5534153
This requires 1.42 for some new names
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Iacbea33299995c537a7ef77b524614ad02c6a559
0c61a5a468 subtly affected the
gadget definition parsing, causing issues with definitions containing
HTML comments or certain kinds of whitespace characters. They would get
saved to the pages array with a trailing whitespace but
Gadget::getScripts() would only return pages strictly ending in `.js`.
Trimming the title before in MediaWikiGadgetsDefinitionRepo fixes the
issue.
Bug: T354385
Change-Id: Iacee432756006060217981a534434fd455285793
Remove the test that expects ES6 to fail by default, instead assert
that invalid syntax fails (as it should). Also add various other
test cases, including a commented-out test for valid ES6 by default,
to be enabled after Ie309e761f8b20640f7c0 in MediaWiki core.
Change-Id: If45856c563518255189687e3b1f620973349fb27
As this repo is not used anywhere in production, there is no backward
compatibility. Any scripts, styles, datas specified in existing
definition pages will get ignored.
Gadget::getJSON() no longer checks isPackaged() – that is now left
for callers - only relevant one is in GadgetRLModule. That was done
because validationWarnings() method needs the JSON page list even for
non-package gadgets.
Bug: T353174
Change-Id: Ic820bc4632981369c72f822fb8b9b7195930eaa6
Follows-up I24af0c2fa75. I forgot that newEmpty uses the "always empty"
EmptyBag, as opposed to an "initially empty" HashBag.
Change-Id: I62075bf685223b31c161508f99f95ee46280450b
* Separate out tests for MediaWikiGadgetsDefinitionRepo and
Hooks::onGetPreferences. Removed hack in fetchStructuredList() for
overriding page content for tests.
* Add tests for ES6 gadgets. For this, ResourceLoaderModuleTest is
converted back to an integration test.
* Removed createGadgetDefinitionPage() test helper method. Now using
MediaWikiIntegrationTestCase::editPage().
* Fixed GDNamespaceRepoTest failure when GDNamespaceRepo is the active
repo, by clearing WAN process cache.
Change-Id: I26b84576a91f6cb0ebae64c5fc1408666d767911
* Add tests for onBeforePageDisplay hook. A simple gadget repo
implementation, StaticGadgetRepo, is introduced for this.
* Add integrations tests for various gadget load conditions.
* Add test for onUserGetDefaultOptions hook.
* Add tests for GadgetDefinitionNamespaceRepo.
* Convert ResourceLoaderModuleTest to a unit test.
Change-Id: I275380c2bfcaa44770b3946a0a468eaaabef70c0
- 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
* 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
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
