This unifies image thumbnail sizes so instead of being random image
sizes, it would be only one thumbsize.
Bug: T323223
Change-Id: Ib7a7a5bce3ce10e60819e6ca056fe30f11e969a5
PageImages::getPropNames can return either array or string,
and PageProps::getProperties accepts both.
But the latter's return value will be different depending
on the type of input: with an array as input, the returned
array's values will be an associative array where the index
is the propname; with a string, it's just the propvalue.
This difference matters because the code below assumes an
array with propname keys.
Bug: T323152
Change-Id: I422951ec0cd5c651b32c65e88a557d49f2f22712
There has been cases of different extensions calling this function
for the same page title within the same web request, leading to
duplicate queries and roundtrips. This avoids those.
Maybe in future we could have APCu cache for it.
Bug: T322528
Change-Id: I9b08b4de2648bf794bfdbfe57de9db433cfd79ee
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
There is only one caller,
this also benefits from the type hints on that caller and
some always-false condition could be removed
Change-Id: Id06b590225b3cf3f0baf331f0aaaad9ef522532a
This will also be added to the interface, but first this
implementation needs to be updated to already accept the
optional new param. Doing it in different order would
cause incompatible declaration warnings.
Bug: T306883
Change-Id: Ia30afcc43a0ecec772cd0a82dd9661e61f31a651
Including regression test for T299798.
Bug: T299798
Depends-On: Idc4ac4eb4e20d8e3e2fdbd093ff75f26d3af0d57
Change-Id: I89fa346651e756d1981a950a8b778020359b86a2
They are documented as being HTML, so look for candidate comments and
strip them, same as we do for the main HTML.
Bug: T298930
Change-Id: I7caf96b8d15f887e0be4c9a24acfd981b3e7a776
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
Remove using of User:getOption since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T296083
Change-Id: Ia6c2fb8a4510cc55e424fc23816e71b2b93732b4
Multiple images are supported according to https://ogp.me/#array.
Facebook suggest an image with at least 1080px.
WhatsApp ignores images >300px.
Bug: T282065
Change-Id: Ibc18df03fbd6f4ec9f4970331e1b5bf930710816
$thumb might be an instance of MediaTransformError, which as the name
implies, is not really usable as a thumbnail and should be skipped
instead.
Bug: T290973
Change-Id: Ie818bd295bfe06c7c0dc0a2ea7dd273c7e0e416f
Replace instances of "blacklist" with "denylist" throughout extension.
Bug: T277955
Depends-On: Ib4985ec2fcb22eafad8f3a7cf9fc3161782a71db
Change-Id: Ibe460cb9691d56a9e83686b53c7629b5404af6fb
