User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: I50d14c08f9d10c5fc7aee2a3908c7ed1d9fad050
The default thumbnail size (SearchResultThumbnailProvider::THUMBNAIL_SIZE),
the code to build a SearchResultThumbnail object from a File object
(SearchResultThumbnailProvider::buildSearchResultThumbnailFromFile),
and the code that provides thumbnails from NS_FILE pages (now already
provided in the hook's $results param) have essentially been adopted
in core and no longer need to be handled here.
Also updated test to reflect that NS_FILE results will no longer be
provided by this extension (since core already provides them)
Depends-On: I2a679b51758020d3e822da01a1bde1ae632b0b0a
Change-Id: I2eafc8556022432929973755d8cd76010ea24f39
Bug: T306883
Including regression test for T299798.
Bug: T299798
Depends-On: Idc4ac4eb4e20d8e3e2fdbd093ff75f26d3af0d57
Change-Id: I89fa346651e756d1981a950a8b778020359b86a2
I added ParserModifyImageHTML to core to make it easier for PageImages
to identify images in the lead section.
This also allows PageImages to stop writing to LinksUpdate properties.
It is one of only two extensions that do that.
Depends-On: I24528381e8d24ca8d138bceadb9397c83fd31356
Bug: T176520
Bug: T296895
Change-Id: I472f4a023969bfde6298eb56112c16d2ae842199
Replace instances of "blacklist" with "denylist" throughout extension.
Bug: T277955
Depends-On: Ib4985ec2fcb22eafad8f3a7cf9fc3161782a71db
Change-Id: Ibe460cb9691d56a9e83686b53c7629b5404af6fb
SearchResultProvideThumbnail was introduced in T250144. In order to fill
search results with the "thumbnails" field it should be implemented in proper extension.
Bug: T250207
Change-Id: I81d5d70f5237d6399b8ec6bec3058d12e40ca142
This is the equivalent of the current 'ApiOpenSearchSuggest' hook
as it once existed in the "OpenSearchXml" MediaWiki extension,
which merged into core and archived three years ago.
See also Ibe244851857ddff3a437acb12c3cc7660eb89089 in TextExtracts
Change-Id: Ifae845925692f2c1113896133e99901782126841
Such @doc… keys are not allowed at this level. They make it to the code
and cause confusion there. I added a test case for an edge case where this
really causes wrong results.
Bug: T212013
Change-Id: Ib391e5639ef5a34f9ee44f8c19b99e1dd19207bc
Supporting changes:
* Update the LinksUpdateHookHandlerTest test case to set the config
variable to its expected value of false.
Bug: T162203
Change-Id: Ic7b4d5ab42f71f6b4cf24cb5bbbbe808341a09e8
This is still only testing negative cases with no page image.
In addition this patch does sort all the hook handlers
alphabetically, and adds a missing PHPDoc block.
Bug: T51859
Change-Id: Iea65f2181dd3cac3ec2ceac191f002f74af3ec24
Unless I'm mistaken this config variable has never been used
in this codebase since introduction in
I64e997d58e4a1b66a8a351d85a3e7df1a77354e9
It's not documented so not clear why it is needed
and not referenced in this codebase.
Change-Id: Ib227eefb77ba2719db277fa80a8bfb958ea6a778
When $wgPageImagesLeadSectionOnly is true restrict
the scoring of page images to images in the lead section.
This results in an additional parse of the lead section of the
content, but this should only happen once after an edit
has occurred and is deferred.
If false all images will be considered as candidates for
the page image choice.
Note that the choice between modes is per site not by
request. This is intentional to avoid having to store 4
different properties respecting license and
article position. As a result when enabling or disabling
this switch on existing setups, there will be a transitional
period where pages previously parsed will show pageimages
as calculated by the previous value of this config variable.
Bug: T87336
Change-Id: I09bdae82515f6e93f5606553259f10b3a10e9eaa
