aboutsummaryrefslogtreecommitdiffstats
path: root/includes/utils/MWFileProps.php
Commit message (Collapse)AuthorAgeFilesLines
* filerepo: avoid PHP 8 warnings in File::splitMime() if $mime is nullAaron Schulz2022-08-231-1/+0
| | | | | | | The warnings were causing CI failures in some upload tests. Bug: T253483 Change-Id: I5c4e0a4d9b154e590daea0fb9d9e04bd086d768b
* phan: Disable null_casts_as_any_type settingUmherirrender2022-03-211-0/+2
| | | | | | | | | | | Make phan stricter about null types by setting null_casts_as_any_type to false (the default in mediawiki-phan-config) Remaining false positive issues are suppressed. The suppression and the setting change can only be done together Bug: T242536 Bug: T301991 Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
* Use the unserialized form of image metadata internallyTim Starling2021-06-081-22/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix Extract typoReedy2021-05-201-1/+1
| | | | Change-Id: I34b2b214034c2e8f297399be6efb6805895b0853
* Document and fix UploadBase::$mFinalExtension being nullThiemo Kreuz2021-02-031-5/+3
| | | | | | | | | | | | | While trying to understand T273249, I followed all code paths and found one that can result in mFinalExtension being null: when a file is stashed, it gets a temporary name without an extension. This patch fixes a bunch of usages where this null might cause type errors. Bug: T273249 Change-Id: Ie8bd84d4637aec5a65ae8b220d9266d36873acc0
* MWFileProps: Hotfix getPropsFromPath() to treat null as empty stringTimo Tijhof2021-02-021-1/+4
| | | | | | | | | | Follows-up 3d84030478779a. It is unclear what null should do, but it is a fact that it used to behave similar to an empty string within MimeAnalyzer so keep that for now, until we figure out what to do with it. Bug: T273249 Change-Id: Ic174253dbe019794f88bdc0f9bbe1e688dda4894
* mime: Document null return from MimeAnalyzer::improveTypeFromExtension()Ori Livneh2020-05-241-0/+3
| | | | | | | | | | | | | | | This method returns null when $mime is 'unknown/unknown' and the file extension is unknown to MediaWiki. The inline documentation and @return annotation omitted this. I don't think this was an intentional design choice, but it's the existing behavior and I'm not sure it's safe to change. Since it is the existing behavior, document it and add a test case, to ensure that any changes to this behavior are intentional. Bug: T253483 Change-Id: Ie6615a4bd9ae77e9ab59cfe76edb237cace693b1
* Unsuppress PhanParamsTooManyDaimona Eaytoy2019-10-101-1/+1
| | | | | | | This is the last repo-wide suppressed issue. Hurrah. Bug: T231636 Change-Id: I3dc939f115bea14848c9c40bc52a7601f86ca0a7
* Use PHP 7 '??' operator instead of if-then-elseFomafix2018-10-211-5/+1
| | | | Change-Id: If9d4be5d88c8927f63cbb84dfc8181baf62ea3eb
* Remove MimeMagicReedy2018-09-231-1/+1
| | | | | | Deprecated since 1.28 Change-Id: I793deb8669e353525464ccd840801e5015c545c8
* Replace MimeMagic::singleton() callsReedy2017-11-271-2/+2
| | | | Change-Id: Ieed41b5d6b0f568fe2872e7754f2feae7868fe7a
* Remove MimeMagic depedency from FSFile and move it to /libsAaron Schulz2016-09-221-1/+31
| | | | Change-Id: Ieaae909b49c798b6e9bed65d15961cefbdaec49b
* Migrate callers to new MWFileProps::getPropsFromPath() methodAaron Schulz2016-09-221-0/+115
* FSFile should not be responsible for handling this much logic. * Make more MediaHandler classes aware of the fact that an object other than File might be passed in. Use the FSFile instead of a useless empty stdClass object. * Also added more fields to FSFile::placeholderProps to make it more complete. Change-Id: I9fe764b2a7261af507c6555e6a57273cf7d00d36
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-23 02:36:17 +0000