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
* Gadget::isEnabled() only requires a UserIdentity, not the whole User
* Gadget::isAllowed() only requires an Authority, not the whole User
Both of those interfaces are implemented by the User class, so this is
compatible with all existing code, and it's easier to call from code
that only has access to a UserIdentity/Authority.
Change-Id: I8ea710c555f6fb7790ae575bb60aab1a05e288d8
Currently, trying to change content model of a page in gadget definition namespace (via either the special page or the API) raises an exception. This uncaught exception has been replaced with a localisable error message.
Bug: T299303
Change-Id: Iad7d353d03cdfb52bf66aa2c9a12bc71a840577c
Hidden gadgets do not have associated user preferences. Adding them to $defaultOptions only causes them to be unnecessarily exported in mw.user.options.
Bug: T299071
Change-Id: Ic55e7f2a9daa405cddd0189de3d32f5825bc336a
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
