* Remove file pattern whitelist for JSHint and JSCS. Instead,
use the ignore list (which we need to specify anyway to avoid
errors when using IDE plugins and/or running these from the
command-line directly.
* Remove redundant '*.json' pattern for banana. '**/*.json' covers
this already as '**' is recursive from the current directory,
otherwise it would be '*/**'.
* Remove redundant 'name' and 'version' property. These were likely
added to suppress warnings by npm-install. However those warnings
are intended for packages published to npmjs.org. For local build
tools, adding private:true also suppress these warnings. For
extensions, name and versions are already maintained in other files
such as extension.json and others.
* Remove redundant '$' entry in jshintrc. There's no need to tolerate
use of global variable '$'. The convention is to use 'jQuery' and
alias it locally, which this extension already does everywhere.
* Set 'jQuery' to false instead of true in jshint globals. True
means it allows and expects this package to assign or expose
the 'jQuery' identifier. However that is not the case. If this
code overwrites jQuery, that should probably trigger a warning,
thus set to false, which means read-only global.
Change-Id: I0b159b6d684f67933e0dae506db1eb3800a6f192
* Schema is located at https://meta.wikimedia.org/wiki/Schema:RelatedArticles.
* Track 'ready', 'seen', and 'clicked' events.
* The sampling rate can be set using the RelatedArticlesLoggingSamplingRate variable.
If the variable is not set, sampling will be disabled. The default sampling rate
is 0.01.
* Events are tracked using a unique user session token.
Dependency: Iea00d534371353c3ae5c06c74a08aa10cb60047b
Bug: T114303
Change-Id: I649d0817cbd10ad734989da548d20ad33e7f7360
Changes:
* Extend the definition of all JavaScript files to include those in the
tests directory
* Run JSHint and JSCS against all JavaScript files
* Fix the existing code style errors in the RelatedPagesGateway
test
Change-Id: Ia6d8fa63e0b86760857d4480a0575b57512fa36b
Changes:
* Add the RelatedArticlesShowReadMore feature flag, which is disabled by
default
* Only consider adding the Read More bootstrap module to the output when
the feature is enabled
Change-Id: I60fc38115257c9a5dbf04b51dbec7f091574d8f6
When no related articles have been specified by an editor we instead
hit request pages similar to the current page using the CirrusSearch
extension's "morelike:" feature [0].
Changes:
* Config variable introduced RelatedArticlesUseCirrusSearch which allows
you to turn on use of the CirrusSearch API.
* Introduce a RelatedPagesGateway for dealing with making the API call
and returning consistent results
* Move the "simple" API call for hydrating related pages fetched from
the wgRelatedArticles configuration variable into RelatedPagesGateway
* Reduce the bootstrap module to just a bootstrap module!
Bug: T116707
Change-Id: Ia0ced1d7ae57c0939d1f5af275aa9d393f1420b1
As of I6a5b43a, WatchstarPageList requires that options.api be an
instance of mw.Api and fails, loudly, when it isn't passed.
Bug: T117467
Change-Id: I7394dea5ab026de1a6709c56d8db4ff72788b59d
If the page has related articles, is in mainspace, isn't the main page,
and the output is being rendered with the MinervaBeta skin then a
"Related Articles" section is added to the page just before the footer.
Separate loading the information necessary to render the pages, choosing
the renderer, and rendering the data so that multiple skins - currently
Minerva and Vector per the mocks - not just multiple resolutions can all
be handled the same way:
* The bootstrap script (ext.relatedArticles.readMore.bootstrap/index.js)
for fetches the page image and Wikidata description; loading the
renderer module; and, finally, notifying the renderer module that it
should render the data, which it does by emitting
"ext.relatedArticles.readMore.init" event using mw#track
* The Minerva renderer subscribes to the event and, when it's fired,
renders the data by passing it to the WatchstarPageList view
Bug: T113635
Change-Id: I651342bdf9796938fa7051828dd13bc6fe774783
While the related parser function sets the accumulated related pages as
extension data on the parser output
(see RelatedArticles\Hooks::onFuncRelated). The ParserClearState
handler, however, sets the empty list as a property, which is then
stored in the DB.
Changes:
* Make RelatedArticles\Hooks::onParserClearState use
ParserOutput#setExtensionData, mirroring ::onFuncRelated
* Add a unit test for the the handler
Bug: T115698
Change-Id: I3deaf1e8ee78944250c3f26315ee2450b444a035
Since CustomData was written ParserOutput now supports the setting
and getting of properties. This patch switches RelatedArticles to use
that. I'm not sure if any other extensions depend on CustomData but
it seems to have served its purpose.
Bug: T114915
Change-Id: I30bd17fd8c43422fe7ab6f58a74565674e15ba1d
Add extension.json and populate it with information from both
RelatedArticles.php and the RelatedArticles extension wiki page [0].
Migrate the hook handlers to static functions operating on static data
rather than having a single, global instance of RelatedArticles so that
the hook handler definitions can be added to extension.json easily.
N.B. During testing the handlers for both the SkinBuildSidebar and
SkinTemplateToolboxEnd appeared to have the same effect so the TODO was
removed but not the handler for the former.
Additional changes include:
* RelatedArticles.class.php -> includes/RelatedArticles.php
* RelatedArticles -> RelatedArticles\Hooks
* Documenting all of the methods of RelatedArticles\Hooks
[0] https://www.mediawiki.org/wiki/Extension:RelatedArticles
Bug: T87965
Change-Id: I9944b9186746386ee18ca28657bb547c00ae2b8c
A performance issue was fixed in the shim(s) generated by
generateJsonI18n.php, so it needed to be updated.
Change-Id: I309d6ffcc739a8f547c9c2ff2d0f6042745f02c7