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 was suggested by a user at commons. The width/height in px is really
a MediaWiki thingy needed for rendering the image, from a metadata prespective
its the original units (aka the image should be 10cm, etc) that is
the information associated with the file.
The dimensions in pixels is still specified in the long description
of the image (the subtitle directly under the image).
Note: After gerrit change Ic58efbf2 is merged, this will cause no width or height
to be displayed for svg images with cached metadata, until they
get purged. I think that's perfectly ok as the width is
available elsewhere on the page.
p.s. I added one semi-unrelated code comment in SVGMetadataExtractor.
patchset 2,3: Fix test (hopefully, how come getting an up to date
version of PHPUnit is so difficult)
patchset 4: rebase
patchset 5: fix my accidental remove of a comment
Change-Id: I312fbd1c935a0095644c3b63c4929632c6f6e387
In EXIF, GPSAltitude is stored as a fraction string like "1/2".
For values below sea level we were negating this value, in order
to represent the sign and the magnitude in the same value. However,
I forgot to convert that to an integer before negating it. PHP was nice
enough to do a best effort conversion of the string to an integer.
This resulted in altitudes below sea level being taken as just the
numerator of the altitude, which gives results that can be significantly
off.
Also add unit tests for the GPS related image metadata stuff. Change the
existing GPS test to use a fractional altitude (Since this issue isn't
appearent if the denominator is 1). Add tests for XMP as well, since
XMP had same issue, and has to do same processing as EXIF stuff does.
In some future time, may want to consider just converting all exif rational values
to real numbers during the extraction process for generally better sanity.
Patchset 2: rebase
Change-Id: I49032b52a4c840b28e667a6a2b8ae23c508df247
Exif test are leaking files heavily on our test server. This quick patch make
it sure we delete temporary files.
Ideally, we should have something like a temporary filesystem backend that
would self destruct :-D
requires r112326: wfRecursiveRemoveDir()
* Replaced 'media' portion of container names with the repo name. This makes it easy for multiple repos to use the same backend without 'wikiId' hacks. Full container names are now like <wiki>-<repo>-<zone> (or <repo>-<zone> if 'wikiId' is set to an empty string).
* Restricted isValidContainerName() more in light of Azure portability and shorted shard suffix.
* Bumped $maxCacheSize to 75 storage paths.
* Code comment cleanups and additions.
Unit tests:
* Updated related tests and marked testBug29408() as broken (I can't find the problem).
* Reduced leakage in UploadFromUrlTestSuite a bit.
Basically, in XMP you can specify partial date (for example 2011-04 for april 2011 with no day).
We were extracting that, and fulling out the day to 01 if it wasn't present (My original resoning when writing
the code was that the nice localized date functions need a full date, but that's a pretty poor rationale for displaying
wrong date). This changes it to just display such year-month things as YYYY:MM.
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
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.
This is Bryan's patch from bug 30640 with a couple minor related changes, plus some unit tests.
This also addresses an issue with preventing too-big images from being scaled from r92279.
I also noticed that image magick's rotation support is broken in 6.3.7 (the version I had installed locally. I've since upgraded) I'm not sure if we should be doing something about that...
I did test this without both image magick, and gd (although only very briefly with gd) both seemed to work well. I didn't test any other image scalars.
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.
* rename testTiffFile to something more descriptive
* unserialize the serialized results before comparing
Also follow-up r92635 - rm an extra wfDl that was outside any functions, and I'm assuming accidentally there (?)
--ta línea y las que están debajo serán ignoradas--
M includes/media/SVGMetadataExtractor.php
M tests/phpunit/includes/media/SVGMetadataExtractorTest.php
Restructure and comment of ImageHandler::normaliseParams(). ImageHandler::normaliseParams() will now output both width/height as physicalWidth/Height, where width/height are the dimensions used by the browser, and physicalWidth/Height are the dimensions of the thumbnail that will be created. This allows keeping the use of unique dimensions for a specified thumbnail width, by forcing client side resizing of 1px-wide images with non corresponding height.
Also fixed a bug where the check for mustRender() was in an if statement where it should not have been.
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.
Unfortunately seem to be hitting a wall right off at checking width & height; BitmapHandler reports back the pre-rotation width & height, leading to the oddity that a file that's clearly 1024px tall and 768px wide reports itself as 1024px wide and 768px tall.
Haven't gotten to generating rotated output to confirm file size. :)
Marked test case as broken pending fix so it doesn't add to surprise regressions in test reports.
