Easier to translate
There is no visible change on Special:ApiHelp/query+gadgets
Also split for list=gadgetcategories&gcprop=
Visible on Special:ApiHelp/query+gadgetcategories
Bug: T285545
Change-Id: Ic40326cd747ffe2153cff7d10e0083bd5e51345e
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
The ResourceLoader module associated with the gadget will have
mobile and desktop targets, but this allows gadgets to disable
themselves on the mobile site if necessary by not adding the gadget
to the page if it's been marked as such.
This also has the benefit of not showing the gadget on the preferences
page if it's not relevant.
Bug: T328610
Change-Id: I4f2b57d1d22f641ff7520358a46cd0e6b2103aa9
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
Added PreferencesGetIconHook to add an icon on the Special:Preferences section.
Bug: T317419
Depends-On: I6d5730d47e7595b1705787995fe5db2fe734d7f5
Change-Id: Ie2505622680573dfe9e50b48976c986cf2512097
* 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
HTMLForm would handle title itself, don't need to set it manually here.
Depends-On: Iaec81a2fb49162f2fc764f143f88e887572a3a0b
Change-Id: I4a9788e853463e51570ba7c04a8bd40f1ed95cfa
Overrides ResourceLoaderModule#getSkins() as introduced in core
with I08a1a59b4eab90d380ca8f874, so that skin-specific gadgets are
only registered client-side if applicable to the current skin.
Bug: T236603
Depends-On: I08a1a59b4eab90d380ca8f874bb6dbba2f399590
Change-Id: I111a67c3119a294afc093b7b64bf0927a56f5b1f
The errorbox class will soon stop working. It and its successor
mw-message-box-error were designed to work with block elements, which
meant that its inline usage caused overlaps and partially unreadable
text above/below it. To fix this, and to be able to use the
Html::errorBox function, I switched to use block elements (<div>s).
Please note that *this causes visual changes* (see screenshots on
Phabricator), and while I tried to test it locally, I might have missed
edge cases, so do tell me if it breaks something.
Bug: T304602
Change-Id: If68b934723722f976668d08a910984f89538a4f2
Avoids expensive re-computations such as that of Action::getActionName, for
each gadget. It is now computed just once in the GadgetLoadConditions
constructor and stored.
This structure makes it cleaner to add more conditions down the line (such as
namespaces and content models - see T204201) and could be reused for user gadgets
(T36958).
Change-Id: I8cbc4bba4d248d9f2ff3a2836450f69970370b1a
The validation appears to be occurring 4 times:
1. JsonContentHandler->preSaveTransform --> GadgetDefinitionContent->isValid
2. GadgetHooks::onEditFilterMergedContent --> GadgetDefinitionContent->validate
3. ContentHandler->validateSave --> GadgetDefinitionContent->isValid
4. RevisionStore->checkContent ---> GadgetDefinitionContent->isValid
Caching the validation result reduces it down to 2.
(Validation in GadgetHooks::onEditFilterMergedContent is to provide a more useful error message than what ContentHandler gives – which is just "Invalid content data".)
Change-Id: I026751b7e9b111b4f0bb9ab5fa0e9737a0385b07
?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
In addition, renamed several instance of $output to $parserOutput to
help readers (and code search!) differentiate between variables which
contain a ParserOutput and those which contain an OutputPage (esp.
since those two classes contain many similarly-named methods).
Bug: T296123
Change-Id: If34330acf97d2c4e357b693b086264a718738fb1
