Fix one instance of bad code that triggers both MediaWiki.Files.ClassMatchesFilename.NotMatch
and MediaWiki.Files.OneClassPerFile.MultipleFound. One more set of errors remains.
Bug: T170583
Change-Id: I45c237b4366477954726a0116fb2d56256276693
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
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
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 adds a few very basic tests to this component. I started doing this
while working on T112865 but later realized I do not need to touch this
extension. However, I started setting up tests and wanted to submit them.
Bug: T112865
Change-Id: I9d00b2baed8da97ffb6af94a6e3b8b63621b876a
Titles that correspond to foreign files aren't included in the set of
titles returned by ApiPageSet#getGoodTitles. However, since
ApiQueryPageImages#execute finds files with wfFindFile, these "missing"
titles can be included.
Add the ApiQueryPageImages#getTitles helper function, which returns the
set of "good" titles union the set of missing titles in the File
namespace.
Also, register the PHPUnit tests directory in the UnitTestsList hook
handler.
The original version of this patch was reverted due to a (stupid) bug
wherein a fatal error was triggered because there was no check for there
being no missing titles in the File namespace [0] and, consequently, an
invalid operand was being passed to the array union operator. This bug
is fixed as well as proven to work with a simple set of test cases.
[0] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FPageImages.git/47137e7ee671c89667d620bc04ac7649b1d9af96/ApiQueryPageImages.php#L31
Bug: T98791
Bug: T114417
Change-Id: I923e88dde3a8ced4921b4192d90b4f3dc4b19e7b
