PHPUnit 3.7.0 was the first version to support @requires extension. At
the time checkPHPExtension() was added in a7901801b4, MediaWiki
still supported PHPUnit 3.6.7.
MediaWiki now requires intl and xml, so I removed checks for those
extensions rather than converting them to annotations.
checkPHPExtension() is removed without deprecation; it does not appear
to have ever been used (and is not likely to be used) in MW extensions.
This is explicitly permitted under the stable interface policy. Even if
it were not, only tests are affected, and they are supposed to fail
anyway if hard deprecated code is used.
Change-Id: I45f9b4c0e120683103cead916f4d4ef58bd11530
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
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
This allows us to populate X-Content-Dimensions without touching the
existing metadata format. Which makes the migration of existing content a lot faster by
only having to run refreshFileHeaders.
Bug: T150741
Change-Id: I2c0f39b2b01f364c3fab997ccc2f874b7f101d8a
For storage repos that support headers (such as Swift), this will store the original
media dimensions as an extra custom header, X-Content-Dimensions.
The header is formatted to minimize its length when dealing with multipage
documents, by expressing the information as page ranges keyed by dimensions.
Example for a multipage documents with some pages of different sizes:
X-Content-Dimensions: 1903x899:1-9,11/1903x873:10
Example for a single page document:
X-Content-Dimensions: 800x600:1
Bug: T150741
Change-Id: Ic4c6a86557b3705cf75d074753e9ce2ee070a6df
* Whack @group Media everywhere
* If testing access to a nonexistent file, make it obvious from its name
* Grammar
Change-Id: I845b484b78b3eb1e5a97f339777d3b7c9ee17712
wfDl() is a wrapper around dl(), which is an evil function and
basically only works from the command line of Zend. Luckily
no extension has ever used this thing, so let's just remove it
outright.
For comparison, here's a list of places it does not work:
- hhvm
- php as apache module
- php compiled with zts support
- safe_mode
- Basically any shared host that cares about security
Most callers are using it to check for extension support and are
actually failing gracefully when wfDl() returns false. In these
places we're just going to use extension_loaded().
While we're at it, clean up some of the test skip logic in the
media tests so we can bail as early as possible if we know we
can't complete the test.
This also immediately removes $wgLoadFileinfoExtension. It's been
enabled by default since 5.3 and falls back gracefully when the
support isn't available.
Change-Id: Ieb430dfc74483731dde51d6e20fa700d641ba1f4
Change some tests to use setMwGlobals to have restoring of globals after
the test.
This also removes some save/restore code, which is not needed, due to
the automatically restoring on tearDown with setMwGlobals.
Change-Id: I8d2ac9f6cc14f0bd4ee8eb851c09f2e71babc6e0
This commit depends on the introduction of
MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4.
Various tests already set their globals, but forgot to restore
them afterwards, or forgot to call the parent setUp, tearDown...
Either way they won't have to anymore with setMwGlobals.
Consistent use of function characteristics:
* protected function setUp
* protected function tearDown
* public static function (provide..)
(Matching the function signature with PHPUnit/Framework/TestCase.php)
Replaces:
* public function (setUp|tearDown)\(
* protected function $1(
* \tfunction (setUp|tearDown)\(
* \tprotected function $1(
* \tfunction (data|provide)\(
* \tpublic static function $1\(
Also renamed a few "data#", "provider#" and "provides#" functions
to "provide#" for consistency. This also removes confusion where
the /media tests had a few private methods called dataFile(),
which were sometimes expected to be data providers.
Fixes:
TimestampTest often failed due to a previous test setting a
different language (it tests "1 hour ago" so need to make sure
it is set to English).
MWNamespaceTest became a lot cleaner now that it executes with
a known context. Though the now-redundant code that was removed
didn't work anyway because wgContentNamespaces isn't keyed by
namespace id, it had them was values...
FileBackendTest:
* Fixed: "PHP Fatal: Using $this when not in object context"
HttpTest
* Added comment about:
"PHP Fatal: Call to protected MWHttpRequest::__construct()"
(too much unrelated code to fix in this commit)
ExternalStoreTest
* Add an assertTrue as well, without it the test is useless
because regardless of whether wgExternalStores is true or false
it only uses it if it is an array.
Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
Followup I68eb9f27
No caller of wfTimestamp can handle the exception, false is always used,
as the method comment says.
See bug 40037 for File related timestamps.
The api result is also not b/c:
<api servedby="mw70">
<error code="internal_api_error_TimestampException" info="Exception
Caught: MWTimestamp::setTimestamp : Invalid timestamp - te"
xml:space="preserve" />
</api>
Change-Id: I1e8c785941d35678f3d12824bdde0ce245572592
Figured since a JS Timestamp class was being implemented
it might be appropriate to create a complementary PHP
Timestamp class. Much of code is taken from wfTimestamp().
Note: Another change (I53dcf547) is attempting a related
issue. Not sure how much of scope overlap there is.
Change-Id: I68eb9f27eebe80df757187f634392e1bcba5551f
Signed-off-by: Tyler Romeo <tylerromeo@gmail.com>
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
This should fix issues reported in http://lists.wikimedia.org/pipermail/wikitech-l/2011-September/055212.html Lots of these tests loaded the exif extension dynamically, but then didn't reset $wgShowEXIF var properly.
Also change some of the markTestIncomplete to markTestSkipped as that seemed more correct.
was starting to get crowded with supporting image files.
This changes the following things
*Moves the media files to a different directory
*Changes the references to the files to reference there new locations
2 semi-unrelated changes
*Modify the README file that was basically giving credit for the images where due to explain what the images are for.
*set svn:mime-type to image/svg+xml for the svg files.
It was throwing 'MWException: Internal error: exif_read_data not present. $wgShowEXIF may be incorrectly set or not checked by an extension.'
Fixed typo in LocalSettings.
This is just some initial tests that really only cover png's. I plan
to add more soon.
Also well I'm here, fix the svn prop on broken_exif_date.jpg from r90421.
