Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ib342f7315b331c18b3f7d9e3c22ff3e4d5d8c7f2
* This patch improves the performance of an
ext:Gadgets regular expression which helps parse
out sections of the gadgets definition page.
Bug: T363773
Change-Id: Ic9e1a181b261ae4d25e9ce2f91ad12f92e9855d9
Adds a "categories" option to the gadget definition, which takes a
list of category names. Enabled gadgets will only load when the
viewed page is in one of the required categories.
Bug: T204201
Bug: T63007
Change-Id: I0ced9507bdab6cacd0baf2a331859099f35b73e5
== 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
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
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
* 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
… e.g. using modern syntax, or avoiding unnecessarily complex
language features. For example, we don't need to call count() when
all we care about is the boolean "is empty/not empty" information.
Change-Id: I13ae802f64627a79b29d1e57ad71486cb2fb977f
This can't do anything for two reasons:
* There are no spaces in the string after the str_replace. There is
nothing to trim.
* The regular expression above guarantees the string starts and ends
with alphanumeric characters. There can't be anything to trim, not
even underscores.
Change-Id: Iea40aafaa2457cdee9d05f105978627d38d9d5b8
* A fixed license header for the file.
* Move class descriptions, doc tags, author/copyright to the
class block. Remove MW-core specific "ingroup" tags such as
"SpecialPage" which has no meaning in an extension and are not
used by Doxygen.
Ref https://gerrit.wikimedia.org/r/q/message:ingroup
Change-Id: I13d9b0ff7a3150180196c9fa58f8a321b14edd22
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
This method is possibly the main cause of DB access in non-database
tests, because it's called from the UserGetDefaultOptions hook handler,
which is triggered by most tests using UserOptionsLookup in any way.
Trying to obtain a DB connection will throw an exception in I96ecf9ff,
so just skip the lookup altogether.
Bug: T155147
Change-Id: I2ac659a472655b2a95e64dcbd3f709e465839b33
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
The class is deprecated and RL will likely stop using it. And even then, this method shouldn't care. The exception is unchecked, so whatever its type is, it's just an implementation detail.
Bug: T328220
Change-Id: I3c87a376ce1d36f4a1d81a435bbc015199c75913
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
== 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
