If $wgMaxImageArea is false, MediaWiki will no longer check if the image
fits within that area before trying to scale it. Extensions can still
use the BitmapHandlerCheckImageArea hook to override it.
This is primarily useful when using an external scaler like Wikimedia
does with Thumbor, which decides whether it can scale images by using a
timeout rather than based on size.
Codesearch indicates that the only extension checking this setting is
PagedTiffHandler, which will be updated in Iefa67321d07f7.
Bug: T291014
Depends-On: Iefa67321d07f79d982388231e02e87e2f18aed40
Change-Id: Id10173bbddb32bc70e036f426369cfbea52cecf4
The software behind this is abandoned and we are migrating djvu metadata
to json instead.
This doesn't affect production as we already use djvudump
Bug: T275268
Change-Id: If45ae5746ba91ba305f93603dc1e3aafba80a369
Use native PHP feature of iterating over key-value pairs
instead of looking up the value if it's used.
Change-Id: Id55f774b3a9d97463b97581c5b2ffe081489863a
* Factor out file read errors and unexpected EOF errors.
* For errors relating to chunk content, instead of throwing an
exception which is silently discarded, just log an error and continue
to the next chunk. This allows the dimensions to be extracted even if
other metadata is mangled.
* As an additional sanity check, verify the CRC of each chunk.
Bug: T286273
Change-Id: I11d0186496324e0bb1bb0a143f438e0368a8e902
GPSAltitudeRef is no longer written to img_metadata, but for
compatibility with old rows, don't raise a formatnum warning, just
ignore the tag.
Bug: T285213
Change-Id: Icc074bc0d7bd6a84f73a26e8dd001be85cbef165
*Handler::getSizeAndMetadata() can return an array without 'metadata' as
BmpHandler does and it's currently causing issues.
Bug: T285490
Change-Id: Ib6bc798508002b1cf2a33325b0ddf6e473d6f287
Gated behind the flag $wgParserEnableLegacyMediaDOM. The scattershot
usage of it is a little unfortunate but isn't expected to live very long
so maybe that's acceptable.
Further details can be found at,
https://www.mediawiki.org/wiki/Parsing/Media_structure
Bug: T51097
Bug: T266148
Bug: T271129
Change-Id: I978187f9f6e9e0a105521ab3e26821e36a96b911
Follows-up I039785d5b6 and I0ccb9971c7b6d99.
It basically cancelled out when the value of error is 0, which is falsy.
Bug: T285431
Change-Id: I79a3c021973e43cf8012a783c24e40bbd33d8652
Before I039785d5b6, it would just suppress errors and return empty value
in which shorten out. Now, it returns [ '_error' => some value ] which
is not empty value but doesn't have anything this method wants either.
Bug: T285431
Change-Id: I0ccb9971c7b6d99937a6b78611cb493795228aee
Before I039785d5b6, it would just suppress errors and return empty value
in which shorten out. Now, it returns [ '_error' => some value ] which
is not empty value but doesn't have anything this method wants either.
Bug: T285431
Change-Id: Ia2bc0982ffaeda0575af1481f9b84faad7d784ad
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
* Optionally store metadata in the database in JSON format instead of
PHP serialization. The new JSON format has a top-level "envelope"
array which gives us a place to store things that are not part of the
handler metadata.
* Optionally split metadata items, putting items above a threshold into
the text table. The FileRepo and MediaHandler must both opt in.
* For staged deployment, the read side of these changes is always
active. Only the write side is configurable.
Bug: T275268
Change-Id: I876ea5c9d3a1881e278f689d2f8a3ae20240c703
Image metadata is usually a serialized string representing an array.
Passing the string around internally and having everything unserialize
it is an awkward convention.
Also, many image handlers were reading the file twice: once for
getMetadata() and again for getImageSize(). Often getMetadata()
would actually read the width and height and then throw it away.
So, in filerepo:
* Add File::getMetadataItem(), which promises to allow partial
loading of metadata per my proposal on T275268 in a future commit.
* Add File::getMetadataArray(), which returns the unserialized array.
Some file handlers were returning non-serializable strings from
getMetadata(), so I gave them a legacy array form ['_error' => ...]
* Changed MWFileProps to return the array form of metadata.
* Deprecate the weird File::getImageSize(). It was apparently not
called by anything, but was overridden by UnregisteredLocalFile.
* Wrap serialize/unserialize with File::getMetadataForDb() and
File::loadMetadataFromDb() in preparation for T275268.
In MediaHandler:
* Merged MediaHandler::getImageSize() and MediaHandler::getMetadata()
into getSizeAndMetadata(). Deprecated the old methods.
* Instead of isMetadataValid() we now have isFileMetadataValid(), which
only gets a File object, so it can decide what data it needs to load.
* Simplified getPageDimensions() by having it return false for non-paged
media. It was not called in that case, but was implemented anyway.
In specific handlers:
* Rename DjVuHandler::getUnserializedMetadata() and
extractTreesFromMetadata() for clarity. "Metadata" in these function
names meant an XML string.
* Updated DjVuImage::getImageSize() to provide image sizes in the new
style.
* In ExifBitmapHandler, getRotationForExif() now takes just the
Orientation tag, rather than a serialized string. Also renamed for
clarity.
* In GIFMetadataExtractor, return the width, height and bits per channel
instead of throwing them away. There was some conflation in
decodeBPP() which I picked apart. Refer to GIF89a section 18.
* In JpegMetadataExtractor, process the SOF0/SOF2 segment to extract
bits per channel, width, height and components (channel count). This
is essentially a port of PHP's getimagesize(), so should be bugwards
compatible.
* In PNGMetadataExtractor, return the width and height, which were
previously assigned to unused local variables. I verified the
implementation by referring to the specification.
* In SvgHandler, retain the version validation from unpackMetadata(),
but rename the function since it now takes an array as input.
In tests:
* In ExifBitmapTest, refactored some tests by using a provider.
* In GIFHandlerTest and PNGHandlerTest, I removed the tests in which
getMetadata() returns null, since it doesn't make sense when ported to
getMetadataArray(). I added tests for empty arrays instead.
* In tests, I retained serialization of input data since I figure it's
useful to confirm that existing database rows will continue to be read
correctly. I removed serialization of expected values, replacing them
with plain data.
* In tests, I replaced access to private class constants like
BROKEN_FILE with string literals, since stability is essential. If
the class constant changes, the test should fail.
Elsewhere:
* In maintenance/refreshImageMetadata.php, I removed the check for
shrinking image metadata, since it's not easy to implement and is
not future compatible. Image metadata is expected to shrink in
future.
Bug: T275268
Change-Id: I039785d5b6439d71dcc21dcb972177dba5c3a67d
Some MediaHandler subclasses were setting custom properties on the File
object in order to cache file-associated state. So:
* Add File::getHandlerState() and File::setHandlerState().
* Put them in an interface, which will be used in a subsequent commit in
MediaHandler::getSizeAndMetadata().
* Use them in DjvuHandler.
* Provide a trivial implementation of the interface, for use in testing
and in the subsequent commit.
Change-Id: Ic365384ff13f7898c1203da38c4405abf03d7563
Basic handler for JPEG2000 files. Both jp2 and jpx are supported by
php's image functions.
No support for:
- metadata
- lossy vs lossless thumbnail
- bucketing
- thumbor
Bug: T161934
Change-Id: I1a72d4dfb034f3ae24661db515cf03b35ec18fa2
In all these cases the property is unconditionally set in
the constructor. The extra initialisation is effectively
dead code and an extra source of errors and confusion.
Change-Id: Icae13390d5ca5c14e2754f3be4eb956dd7f54ac4
The control characters are presented as text, not actual
control characters, so the regexes to replace them are
incorrect.
Added a column and para to the Djvu text on the first page
of the test LoremIpsum.djvu file
Bug: T230415
Change-Id: I4970bc30b3935ce4da062ee7ff687aa667027a00
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
This issue type was globally suppressed in
I849ac4f120fd15b483e8939d4db45c98dc351259 to make reviewer easier.
This adds inline suppressions or @suppress directives on function
docs for false positives, mostly restoring those removed in
I849ac4f120fd15b483e8939d4db45c98dc351259
Bug: T231311
Change-Id: I1b1d814bd907e9d49fcc39f777982936574fc7c6
