$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
* Images on pages can be localized (eg. SVG text)
* Allow API consumers to select the language the images are rendered in
Bug: T257082
Change-Id: I05f498444c55aea9028a58de80e21ba1e236bf02
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
Avoid array_map/array_flip + foreach when doing the simple thing also in
the foreach
Swap Title::newFromText to Title::makeTitle to avoid reparsing the
string
Bug: T237068
Change-Id: I745cb9bd817a4b2274c6f778c38c58846ef318c1
The file page for an image should include the `og:image` meta tag. Thus,
a thumbnail is shown for the image when posting a link via social media.
Relates to Ide250d489a1ceedd7e896a3b44471752f0971fb1.
Change-Id: I81435289a4a6c7749462ba447aa626120a9c821c
The hook is called during page move. If you try to fetch the current
page content from the replica, it won't be there with the specified
title, causing an exception.
Bug: T221763
Change-Id: Ib91bf399f251fc715d8f27a4f8f7f4c9db9d30c8
This allows to use floats in the $wgPageImagesScores configuration.
Before, decimal places have just been cut off with no warning. I find
this pretty unexpected. When I see the terminology "score" being used,
I always think of float values. I checked all the code that consumes
these scores (it is all internal to LinksUpdateHookHandler), and it's
all fine with floats. I don't see a reason to forcefully cut decimal
places off.
Bug: T212013
Change-Id: I0f1f0ea0865f07b3e58a2fc142dcd838eb687c97
This patch is motivated by Iad694e0.
* I rearranged the code a little bit to avoid a duplicate line of code.
* I added a ksort() and a comment explaining it.
* Additional tests demonstrate why the ksort() is needed.
* I had to refactor the tests a little bit to allow for more test cases
that have been missing before.
Bug: T212013
Change-Id: Ia96dc8c6cf57ddcea410a7300756d0013052ac79
Original image info is now a first-class output property, and the
'original' property of the 'thumbnail' object has been deprecated since
December 2016 (with an API warning provided since then when original image
info is requested). It should be safe to remove at this point.
(N.B. The 'original' property was an undocumented piprop before the format
update, and the legacy output likely sees little if any usage.)
Bug: T152163
Change-Id: I73b476f9e50c14f705a30e20bc836b8db371f5f0
The following sniffs are failing and were disabled:
* MediaWiki.Files.ClassMatchesFilename.NotMatch
* MediaWiki.Files.ClassMatchesFilename.WrongCase
* MediaWiki.Files.OneClassPerFile.MultipleFound
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: Ibb3e8fbef168f886d2385565df85015c08b2f02a
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.FunctionComment.Missing.Public
* MediaWiki.NamingConventions.LowerCamelFunctionsName.FunctionName
* MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.NewLineComment
Change-Id: I3554682b5c8686299dc8cf23a3ec8c59514ff008
This tag is useless and does nothing without og:title and
og:description also being present, which is not the case
right now. A more complete patch should re-introduce all
three tags in one go.
It is also questionable if this tag belongs to this
extension, because it is explicitly said that the image is
an optional element of a Twitter card. og:title and
og:description are not optional. og:description would
probably be set by the TextExtract extension. This means
this Twitter card tag belongs more to TextExtracts and not
to PageImages.
This reverts commit 2e83a2c1dc.
Bug: T157145
Change-Id: I17ffe8f83d91156a79facb4c35b4a15ecc49f108
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
The maintenance script to populate free images has finished executing.
Follow-up on I1d35e965dc37c8c4ecdcc43313b3198e951e1978.
Bug: T152216
Change-Id: I32669e937efa6f5566eee582b911d170a32762e3
It's useful for API consumers to have the dimensions of the original
image so that they know the bounds within which they can safely rewrite
the thumb URL (bearing in mind the prerendered widths[1], in the case of
WMF wiki consumers).
This change adds an 'original' property to the page object, containing
the original image source URL along with its width and height, when
original image info is requested.
A warning is added when original image info is requested, noting the
format change and warning the consumer that the original image URL will
no longer be provided within the 'thumbnail' property in a future release.
[1] https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L17535
Bug: T152163
Change-Id: I9d937f73a974dfb099b93552405531464b8ad3ae
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
Very few of these jobs seem to be finishing, due to some
replicas being so far behind we get DBReplicationWaitError
thrown, which causes the job to be restarted. Catch and log,
but don't stop processing because of it.
There is also a problem with jobs that blow out the memory limits,
but not sure what to do with that.
Change-Id: Idffcfad76936f5e62e9018c58f2cb57db35af4b8
Trying to run this script in the cluster fatals out due to memory
problems somewhat regularly. The --start option helps to restart
it where it fell down, but when trying to run against hundreds of
wiki's that is a one-off solution that makes ensuring everything is
actually visited a pain.
To try and isolate errors add an option to push the parsing into the
job queue. There is still the possibility to miss pages, but job queue
retries should take care of us for the most part. Attempts to keep
load down on the databases by making sure no more than a specified
number of jobs are queued/processing at a given time.
Bug: T152155
Change-Id: I3a4e3a415b2f03de0bb36ac0515241e950130fde
The mobileview API directly accesses the page image,
bypassing the PageImages API.
I1d35e965dc37c8c4ecdcc43313b3198e951e1978 fixes the issue for
the PageImages API.
This patch fixes the issue for the mobileview API.
Change-Id: If6cbb82f01fa298945c615a2f25e972a9d767d58
Page images was updated to have a split between the 'best' page
image, and the best free page image. Unfortunately the deployment
plan didn't take into account that the default 'free' would be
pointing to an unpopulated page prop, which will not be populated
until LinksUpdate has run for every page on every wiki which could
take weeks or months.
To restore some semblance of order, make the default point at the
currently populated field. A followup will need to be done to
populate the appropriate field.
Bug: T152155
Change-Id: I1d35e965dc37c8c4ecdcc43313b3198e951e1978
The API accepts a new query parameter `license`, whose
value can either be `free` or `any`. `free` is the default value.
When the value of `licence` is:
* `free`, then only the best image whose copyright allows
reusing it will be returned;
* `any`, then the best image, regardless of its copyright
status, will be returned.
Bug: T131105
Change-Id: I83ac5266e382d2d121aff3f7d28711787251c03b
This fixes a fatal which is blocking deployment of 1.29.0-wmf.1
refs T149059 fixes T149849
Bug: 149849
Change-Id: Ieb61585af3aa60b7af58597091151d0b494b2fd6
* Do not "return true" in hook handlers. I was told it's good practice
to either return false on failure, or nothing/null.
* Remove "static" from method that does not need to be static.
* Make some type hints more specific.
* Add missing imports. I wonder how this can work without the imports.
My PHPStorm complains.
Change-Id: Ia0e980ff99f0e004d700b22dd07ff17f04bed4ec
Fetch the extended metadata for every image, and if the NonFree key
(provided by CommonsMetadata) is present, rank down the image.
The check is run on LinksUpdate so changes to image copyright
templates won't have effect until the page is reparsed.
Unlike other weights, the work of extracting the weight factor from
the file/page is wholly done on LinksUpdate, instead of doing most
of it on parse and storing as ParserOutput extension metadata.
This is to avoid getting the article page parsing and the file
description page parsing conflicting with each other.
Bug: T124225
Change-Id: I21111ecbc80ded864806a2a93002f3254c3c68a9
User::getOption() already handles that, and this code bypassed the hook
in User::getDefaultOptions().
Change-Id: I41f9df177988dffd62de0060cb691a97161729e4
This patch only moves existing code around, but does not change any
implementation detail.
I found it very suprising that all code called by these two hook handlers
is 100% exclusive to these hook handlers. There is zero interaction
between these hook handlers code and all other code. Why is it in the
same file then? And why is it all static? It doesn't have to be. I
had to change literally nothing, except cutting and pasting, removing
all "static" and replacing all "self::..." with "$this->...". That's
all.
Change-Id: I7fdc582db425d3b95f7d02934b439eb9c102e712
This patch only moves existing code around, but does not change any
implementation detail.
I found it very suprising that all code called by this hook handler
is 100% exclusive to this hook handler. There is zero interaction
between this hook handlers code and all other code. Why is it in the
same file then? And why is it all static? It doesn't have to be. I
had to change literally nothing, except cutting and pasting, removing
all "static" and replacing all "self::..." with "$this->...". That's
all.
Change-Id: I5ffe6fdf4e57135e6f3b32636c80f22be758607c
