* 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
* 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
When using the Gadget definition: namespace, link to the definition
pages from Special:Gadgets. Also change the wording of the links
to edit the names of the gadgets, to disambiguate them.
Change-Id: I327a4cfa9846edec60e1aaafc674cd66f4e0beae
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
Remove using of User:getOption since this method
will be hard-deprecated. Now it is soft-deprecated.
Bug: T296083
Change-Id: I140cbd5655ac4ae0ad7b6d30c5e6bae0008aba07
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
When viewing pages, the 'withgadget=' query parameter can be used in
the URL to load a gadget that isn't enabled by the user's preferences.
The gadget is only loaded if all other conditions are still satisfied
(supported skin, supported targets, required user rights).
Bug: T29766
Change-Id: I5b30d4e0010561685eef661a515e2892045bb776
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
Without the default the preference is never deleted from the database,
even it was disabled by the user.
Bug: T291748
Change-Id: I1010e260fda118cbea83ad39e33055e403e37630
Use it instead of Content::getDeletionUpdates and Content::getSecondaryDataUpdates.
Bug: T285730
Bug: T285729
Change-Id: Ie4ea0917f120809be59e2b7afad51cd189d64dd1
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
The context source is not set at this point and the global request is
used and logged:
SpecialPage::getContext called and $mContext is null. Using
RequestContext::getMain(); for sanity
Change-Id: I50f96f8e6517ec7221c4b82872208787af63e12b
On mediawiki version 1.36 and before, just returning false in this hook can't display error message by default.
Set $status->value manually still to provide backward compatibility.
Bug: T280312
Change-Id: Ic80fd227668794c21299a3f7879f61a20a2f55bd
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
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
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.ObjectTypeHintParam
* MediaWiki.Commenting.PropertyDocumentation.MissingDocumentationPrivate
* MediaWiki.Commenting.PropertyDocumentation.MissingVar
* MediaWiki.Usage.ExtendClassUsage.FunctionConfigUsage
Additional changes:
* Dropped .inc files from .phpcs.xml (T200956).
* Added the `wikimedia/mediawiki` profile in .eslintrc.json (T262222).
Change-Id: I73a5f722738dff75c623cf631bfa7e3dcf8d6f82
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
Additional changes:
* Added .eslintcache to .gitignore.
Add an explicit check before using the parameter.
Depends-On: I92ecaa9c14e5c8ba32d152a9e2246a2144b1c7da
Change-Id: I255237574e76f1c0d92f376bc8cbb81f7cb4ed14
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
This change avoids the flash of missing sorting buttons while loading,
but only with I0b446d18f47428d8c0c4aed78b75de16fe106218 in MediaWiki
core included in MediaWiki 1.33 or higher.
Depends-On: I0b446d18f47428d8c0c4aed78b75de16fe106218
Change-Id: I6efb7a995589a7b93691d5ebd37ae8ac42f0a971
This change ensures that gadgets that are enabled by default are sorted
with a higher value than the other gadgets.
Change-Id: I02fab73c85b4c3580e484832c91a7314c797e978
Due to some of the portions of the gadget list items being optional
it's not consistent whether or not they should be separated by
a line break.
When two pieces of text follow each other, there should be a line
break in-between.
When a piece of text is output afte a list, however, there is no
need for a line break as anything after a list would already
become its own line. Printing one anyway causes a blank space
to show up, which visually causes it to appear related to the
next gadget.
Fix by setting a boolean after each portion to indicate whether
or not it should be followed by a line break.
Also improve the code a bit with comments and use Html instead
of Xml.
Bug: T204616
Change-Id: If65e170746898999dd8f5351004eeaf49b340ab2
The lengthy and localised descriptions make it hard to scan and
identify the actual rights themselves. They are meant as descriptions
to explain what a right is, not to identify the right itself.
It should probably be more similar to the list of checkboxes
on Special:UserRights. For now, kept the descriptions as tooltips,
but could also remove them entirely.
Change-Id: I29f68ffd5a8d002b65384f3762fb9e5631c13def
The wrapper tags that we have to create when using the 'rawrow' option
would have to be different for OOUI and non-OOUI preferences forms,
making it impossible to support both at the same time.
We used it in order to generate `<td colspan=2>...</td>` rather than
`<td></td><td>...</td>`, and make the description span both the label
and the input columns. However, this is not necessary, because the
label column is entirely hidden on this page of preferences, as all of
the preferences have no labels.
Bug: T203202
Change-Id: Ib9510a8bfb2430fdda3988d88628c9f0c509c6d0
* "raw" and "rawrow" are documented as booleans.
* "raw" does not have any effect if "rawrow" is set.
* "label" does not have any effect if "rawrow" is set.
* "noglobal" refers to GlobalPreferences. It does not have any effect
because "info" fields are blacklisted anyway.
https://github.com/wikimedia/mediawiki-extensions-GlobalPreferences/blob/master/includes/GlobalPreferencesFactory.php#L75
Also see my longer comment in I1ab2bc6 where I explain all these changes.
Change-Id: I7b4e08b45070ae07935e1cd59091b3d608583e5b
This change raises MediaWiki version requirement to 1.32.
Change-Id: Ieffed829bf5a8e1f138fd5f63518e415cebb1287
Depends-On: I193f5b9a95430b0a05573c361715e053e5411e32
The user's preference usually reflects the displayed skin, however this isn't
true if the `useskin` URL query is set, or MobileFrontend is being used.
This fixes gadgets being displayed on the wrong skin when using `useskin`,
and allows mobile-specific gadgets (using `skins=minerva`).
Testing if the gadget is allowed in the current skin is split out from
`isAllowed` to `isSkinSupported` to enable a future patch showing gadgets
on preferences regardless of if they are allowed on the current skin.
Test coverage is added for both functions.
Also fixed another test which wasn't working, presumably because the placeholder
user didn't have the "read" right, so the section wasn't being kept.
Bug: T199478
Change-Id: I21febe92d54d6d0b89925f902581cc2739d824fb
DataUpdate is a specific implementation (currently the only one), while
DeferrableUpdate is the interface. Binding against the interface is
enough, and what the base classes already do.
I'm also removing a line of meaningless documentation. "Creates an
instance of this class" is a general description that is true for all
constructors.
Change-Id: Ia6dc86b078628db5e0ab68ef46bf0396567b767c
Depending on GadgetRepo::singleton() to return a specific implementation
is fragile. Pass each created/updated/deleted page to
GadgetRepo::handlePageCreation/Update/Deletion() and let each specific
implementation deal with it.
Use LinkTarget to be TitleValue compatible for the future.
Change-Id: Ibe2e26d12369a897c53757adf621926f62af7f7b
This is a resubmission of 86905f8, which was reverted because
of a bug in ResourceLoader that caused gadget styles to be
concatenated in the request for site.styles (fixed: 15ca48ad).
This change ensures that gadget styles no longer get combined with styles
from core, skins and extensions in their early stylesheet request. Instead,
they now load after the 'ResourceLoaderDynamicStyles' marker directly
after the site.styles module request.
Bug: T147667
Change-Id: I16b9901de78e7ee913c4faa55ff9fc9c77fe73ba
… as well as update a line of documentation I had stashed. I think this
does not need it's own patch, or does it?
Change-Id: I99eee1f7b5ec96c1c75e73d66200bc41807452fa
This ensures that:
* It will load in the request for module=site.styles
instead of the request for core, extension and skin modules.
* It will load after the 'ResourceLoaderDynamicStyles' marker
instead of before.
Bug: T147667
Change-Id: I762a188b8ddfc192121f89ef01afaa4b5bf31b98
This avoids purge problems due to layered caching. The message cache
is known to take a while to regenerate and uses lockTSE=300.
Bug: T157210
Change-Id: I418e160ddb61c4d3654780f5d2bbb14bc2827e2a
Ref discussion on T42284.
Test plan:
* Create gadget A with a .css file only. (Maybe mark as 'hidden')
* Create gadget B with .js file, and peers=A.
* Verify that enabling B will result in B being loaded as general module,
and A being loaded as page style module.
Change-Id: Ib6207e72c576ff387ecdba685a063bdfbb828199
Follows-up 152484566, which added support for it in Gadgets 2.0, but
it's easy enough to make it work in existing definitions as well.
That way, people can stop using 'rights=hidden' hacks.
Bug: T33150
Change-Id: Idd6944a9ad38279e117c1a02a4b5fd0343455ba0
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
For consistency with rest of MediaWiki, especially CodeEditor.
Note that this will cause dirty diffs for any definition pages created
before this patch, but that's not a big deal.
Change-Id: I3ed4b4aa7d18c489b9a322f67ea6ea31e610a257
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
In the backend, allow:
* Adding dependencies on messages
* Marking gadgets as hidden so they don't show in preferences
These cannot be used by MediaWiki:Gadgets-definition gadgets, but will
be used by Gadgets 2.0 gadgets.
Change-Id: I55e97de9d631ae001ccc0164db172ba9c5689a34
