That is causing T350726 and we already set the field in one line above
Follows-Up: I63ac37c2b73073e8e323f6627785955196cd148c
Bug: T350726
Change-Id: I9f28e326aefa206fe8f4d3f6a1038740fed9b0d4
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
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
$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
As we switch ParserCache to JSON, we can no longer serialized
class instances in extension data. PageImages was writing the
full set of properies it received from Parser into it's extension
data, some of which are sometimes class instances. Instead, only
write the nessessary subset of data into extension-data.
This change is completely forward and backward compatible.
Since before this change we were already writing the same array,
but with many additional unused properties.
Bug: T266251
Change-Id: Ieb4a139465159611e6b3a99c4b68c3c174b1944f
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
