composer:
* mediawiki/mediawiki-codesniffer: 28.0.0 → 29.0.0
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamTag
npm:
* eslint-config-wikimedia: 0.11.0 → 0.15.0
The following rules are failing and were disabled:
* no-jquery/no-parse-html-literal
* grunt-eslint: 21.0.0 → 22.0.0
* grunt-stylelint: 0.10.1 → 0.13.0
* stylelint-config-wikimedia: 0.6.0 → 0.8.0
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
* Removing manual reportUnusedDisableDirectives for eslint.
Change-Id: Iab538420d73bbbebfd05cf815ab06773f16da8da
Currently, the extension queries the prop=description api to fetch the
description, but this api is only available if Wikibaseclient is installed.
Let's support other sources to fetch the page description from, too, or
disable it (by default) to sabe 85 bytes from each response by avoiding the
warning returned from the api when prop=description is not recognized.
A new configuration setting has been added: RelatedArticlesDescriptionSource.
It defaults to false (no description is fetched), but can be set to one of
those string values:
- wikidata: What's being used right now on WMF wikis
- textextracts: Extension:TextExtracts provides the prop=extracts api.
- pagedescription: Extension:Description2 provides a description page property, that can be queried by prop=pageprops&ppprop=description
Bug: T230947
Change-Id: I34410334ba9d6db1f686c7efb5722e2a51957145
This allows skins to determine where the cards appear in a consistent
fashion with other extensions, and require minimal special handling from
the extension itself.
Also change default settings as to when RelatedArticle cards will appear
- keep the whitelist to allow projects to configure their usage such as
in the case of only wanting it on mobile, etc, but now that it should
just work in any given skin, default it to on for all so that it's easier
for the average third party to install for whatever use.
Note that this default setting change will not affect WMF wikis, as
wmgRelatedArticlesFooterWhitelistedSkins is explicitly set in the
wmf-config regardless.
Bug: T181242
Depends-On: I5b0ad889e633fde88c392577ce5373c81fc5486a
Change-Id: Iebd759c0d1a536768d18953f372664df762d9e04
Equivalent to latest 'article' icon in Design Style Guide and OOUI.
Also updating `.list-thumb-none` class to align icon and simplify
maintenance.
Bug: T222717
Change-Id: I49a89afa3d370abc4cf282a0bf8d44ee2751aa78
* The extension already uses 'null' as placeholder in RelatedArticles
instead of empty array. Update the doc comment in RelatedPagesGateway
to reflect this (its code was already using the default operator
to fallback to empty array, given empty arrays are not falsey in JS,
but null is).
* Omit the key from the mw.config output in <head> on page views,
when the value is null, given this is redundant information and consumes
additional space.
Bug: T219342
Change-Id: I367f9d9423d66611d73d56f8a769d86d14d3de8b
Bundle these with the module that needs it instead, this means
1. It is naturally only downloaded on pages where it is needed.
2. It doesn't block download/parse/render of the article HTML.
3. It doesn't delay time to mw.loader.load() for interactive
functionality.
Bug: T219342
Change-Id: I5c6809392b0621bd0d58049597f6c0306e572607
This enables use of module.exports and require() within the module,
and makes it easy to bundle additional data and scripts generated
by the server (without needing to subclass FileModule in PHP).
In particular, to bundle mw.config values with the module.
Currently the extension is adding these to the <head> of all
articles which delays rendering of the article content, and the
time to when JS can start to be fetched.
See <https://phabricator.wikimedia.org/T219342#5116773>.
Bug: T219342
Change-Id: I3f174418af8bfd83b0faabe484226e323714cb5b
