* 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
Its not just ogg files that have a duration, animated GIFs
and APNGs do too.
After If172a1cba is merged, this will show up in the api.
Change-Id: Ie7cf00df34950ae404fcf655dd16397a273e5523
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
This avoids on image page:
ContextSource::getContext (FormatMetadata): called and $context is null.
Using RequestContext::getMain() for sanity
Change-Id: I92774e1a88f03d44967d1797c6c2b8a31c1b10fc
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I8ebfbcea0e2ae2670553822acedde49c1aa7e98d
Instead of always generating thumbnails based on the original,
this adds the ability to generate thumbnails based on
references buckets. The buckets themselves have their
generation chained following the same process (smaller bucket
generated based on bigger bucket). In situations where no
suitable bucket is found, the original is used, like it used to.
This is entirely optional, as most non-WMF wikis would probably prefer
to keep generating all thumbnails based on originals.
The quality implications have been verified through a survey
aimed at Commons users and people actually preferred the chained version.
Presumably due to the multiple passes of sharpening which maintained
visual details better for small thumbnail sizes.
Change-Id: I285d56b2024c81365247338f85c1e0aa708cb21e
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/600
Bug: 67525
Currently file metadata is handler dependant. However they usually
end up extracting the same type of data (author, date, etc) plus
one or two handler specific things. This adds a handler independent
interface for getting metadata that is likely to be common for all
types of file (At the moment, this is the exif/iptc/xmp information)
This commit used to also contain stuff adding parser functions,
which is now split to its own commit. This commit is needed
by a bunch of other commits, in particular I0d957891e0.
Change-Id: I43d9252f69dc5b8ba0b848cf40aa1b97329c85ae
This shows a warning on the image description page if the image
is animated, but thumbnails won't be. This includes
gif images that are too big, but also svg images that are animated,
and APNG files.
The message used is file-no-thumb-animation, but will also
check for file-no-thumb-animation-<image extension> so that
admins can do per image type explanations. Gif files have a built-in
explanation that is slightly different (Since its do to resolution).
Ideally one would pass the resolution limit to the gif message,
but I couldn't think of a clean way of doing that. (Also might be
complex to explain to user. They aren't used to resolution as a single
number but as a width x height type thing).
Moves isAnimatedImage from ImageHandler to MediaHandler, so I could
safely use it from any handler class.
Change-Id: I42ee11d889e0c41de53d0951f55a4338ca55311d
Hope I did this in an ok fashion. svn merge --re-integrate was giving me issues
so I just essentially over-wrote my working copy with the version at img_metadata.
