Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I2f17c7e8c6365795f7a54738b0e607b6f35c9df2
Parent class constructor gets type-declaration in 1145328459
Remove simple doc-blocks without further information
Change-Id: Id2264c743077188e2b4f6a66b5d32d67716ed182
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I6b49b9837ed6d3dfdd8a4bc0420848c09fcb1540
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I780e57da1ea02eb333cf61abd999dc737acf20d1
The parserTest "PageImages with toc and image in heading" covers the
case of PageImages comments being left around in TOC data.
Depends-On: I10f96435f892b188cffe64b92cdf2701a3e2058b
Change-Id: Ie6760dd25f937d4f6acbab1c0e1475b54878d4ed
Notably:
* Utilize the new ??= operator.
* No need to count when nobody cares about the number.
* More robust ratio calculation.
* More straightforward check for the "notpageimage" class name. We
don't need an array of all the classes when all we care about is a
single, specific class.
* Fix misspelled "no(t)pageimage".
Change-Id: Ibad1d395a5438bc58e026022d08c38fe54c48653
… as well as the properties that are initialized via the constructor.
Also update some PHPDoc comments.
Change-Id: I2f1dc5345b4a9d00e01d701ad04d42b28aa2f96a
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ie00aedfe607665e8a38ee4ce2475f25b82a1d8cf
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
That is causing T350726 and we already set the field in one line above
Follows-Up: I63ac37c2b73073e8e323f6627785955196cd148c
Bug: T350726
Change-Id: I9f28e326aefa206fe8f4d3f6a1038740fed9b0d4
Now getPageImageInternal returns null instead of false.
Fix the comment in fetchPageImage(): false means no cache.
Also add a return type hint to PageImages::factory().
Change-Id: I696f24390be530e7eea21957e0e46752d1bb3030
The public static function PageImages::getPageImage must stay unchanged
because this function is called by other extensions.
Change-Id: I73f7253581ebc894ef6dcd41bd4713f7d9f53421
Easier to translate
There is no visible change on Special:ApiHelp/query+pageimages
Enable use of existing paramvalue apihelp messages for pilicense
Bug: T285545
Change-Id: Iea70490705af9224b3c93669bd5a6e9be7043410
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
