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
See I674bf7f6c1b21ffc9870aa84382479af5f966561 for an example in the
PdfHandler extension.
Bug: T89765
Change-Id: I3c4b7af7284b5e16e458dd72de789e74db489895
This avoids on image page:
ContextSource::getContext (FormatMetadata): called and $context is null.
Using RequestContext::getMain() for sanity
Change-Id: I92774e1a88f03d44967d1797c6c2b8a31c1b10fc
BitmapHandler has a lot of generic-ish functionality that could
be re-usable by extension classes (Such as how it organizes
$scalerParams array, or various image magick escaping methods).
However it's combined with a lot of very format specific things,
such as the shell-out call to image magick.
Try to separate out the more generic stuff into
TransformationalImageHandler. In order to do this, I also made
canRotate, autoRotateEnabled, and getScalerType non-static. No
extensions in our repo appeared to be using these methods, and they
don't really make sense to be static (imo).
In particular, I think code duplication can be reduced in
PagedTiffHandler by extending this new class. See comments
on I1b9a77a4a56eeb65.
Change-Id: Id3a8b25a598942572cb5791a95e86054d7784961
- 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
Allows media handlers to signal that thumbnail generation
for this file is expensive and should be throttled more agressively.
For now this is only done for large TIFF files.
Bug: 65691
Change-Id: I01b34a1d46745649f179fdee435a8cfb19c5474e
MediaHandler::getLongDesc and getGeneralLongDesc have same
implementation, so forward one method to the other. Same for
short.
Also get rid of one unnecessary $wgLang global usage.
Change-Id: I688e27ce2b9cf950defa16ec6bce2e52c5959b03
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I7f605aa9e117b5fd80d9b1440864fe526d2b14a5
It was being called in File::getLength, but was only implemented
in a subclass, that's not even in core. Any method of a handler
class called from a method in File class should work on any
subclass of MediaHandler.
Change-Id: I94eda90ec3dd64b6ff2e3a5732aa539366cec521
Currently we support rendering SVGs in multiple languages,
but there is no mechanism for users to discover what languages
a file is available in. Show this information on the image page.
At the moment, if unspecified we always default the language to
english (I believe to avoid mass cache splitting, especially
if most languages wouldn't have a translation of the file in
their language). This code was written in such a way so that
this assumption should be changable in the future if we so
desire.
Long term, Jarry has a super cool svg translation extension
which would take over some of this. However I still believe
we should have an interface for this in core, since we do
support the different language renderings in core.
Change-Id: I84506436514e09d71200aa2db3932aa001b55c71
Whenever a rendering commands emit a ton of errors (spotted a case
generating 125MB), the call to trim() makes PHP copy the stderr which
might exhaust the remaining available memory.
The new constant MediaHandler::MAX_ERR_LOG_SIZE = 65535 is used to
substr() the error log before it get trimmed and logged.
bug: 57985
Change-Id: Ibd4cf0331529d323a68273163ac230b07a6c6108
BitmapHandler::logErrorForExternalProcess is a wrapper around
wfDebugLog( 'thumbnail' ). It got copy pasted from some other class at
one point.
This patch move the method up to general class MediaHandler and makes
other child class uses it. The method will thus be available to
extensions such as TimedMediaHandler.
The reason I am doing that is that trim($err) generates a copy of $err
which causes a memory allocation fatal error whenever $err is larger
than the remaining memory allocatable. The patch will let us fix the
bug by only altering one part of the code.
bug: 57985
Change-Id: I5657f07d6e2cca05d53f2a5c30ec23622c171343
Part of the point of this, is to add a hook to allow extensions to add
their own metadata (I intend to create a companion extension to parse
Commons description pages - I5e6bc45f9751)
It's hoped that this would provide a simple system to get file metadata,
and would be able to return information on any wiki (even without any
extensions installed to provide additional information). So it could
fallback to exif data, if there's no better source of information for
the file available. It's also meant to be done in such a way that, in
the future, when Wikibase is deployed on Commons, it could be integrated
without too much fuss.
marktraceur changed this patch to be a little less heavy-handed: it will
now return unformatted data by default from the API, but there's also a
method for formatting that data in the way that bawolff originally
intended. I'm still trying to figure out if there's much use in that
method, but for now it's not particularly useful.
Change-Id: I77303d8e535fc1c42e14cfb853814e5c434a81ec
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 way we know we can always safely call getRotation on any image.
In particular, PagedTiffHandler doesn't extend BitmapHandler, and I
want to make VipsScaler work with PagedTiffHandler, and it calls
getRotation.
Change-Id: I63f2be2a6f31398918b8562e15343f8a839d91c1
Use MediaHandler::parseParamString to parse the parameter string
of a thumbnail. This seems to make much more sense given the
design of the Handler class. Also mark ExtractThumbParameters hook
as deprecated.
This should be reviewed by someone familar with the 404 thumbnailing
infrastructure. I'm unclear if there was a reason for why it wasn't
using MediaHandler::parseParamString in the first place.
Bug: 49629
Change-Id: I43a0e7d6f0e45536e4e24b72140157791f5f027f
getPageDimensions returning false for failure wasn't being handled
properly, causing ugly output. The doc comment on that method was
wrong as well.
Most notably causing random whitespace output:
https://commons.wikimedia.org/wiki/?curid=22151015
(screenshot: http://i.imgur.com/c21EpVx.png).
Bug: 41281
Change-Id: I1a49474309e15808928f877dfc29ae366d028928
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
