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
Found by running tests under a version of PHP patched to report
case mismatches as E_STRICT errors.
User classes:
* MIMEsearchPage
* MostlinkedTemplatesPage
* SpecialBookSources
* UnwatchedpagesPage
Internal classes:
* DOMXPath
* stdClass
* XMLReader
Did not change:
* testautoLoadedcamlCLASS
* testautoloadedserializedclass
Change-Id: Idc8caa82cd6adb7bab44b142af2b02e15f0a89ee
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
SVG files support having different renderings based on language.
We support changing the rendering language, but we offer no
discoverability of what languages are available.
Long term Jarry's TranslateSVG will hopefully be used and have
all the associated awesomeness. In the mean time, we should
probably have some indication on the image page what languages
are available for the SVG. This is step 1 (extract the language).
I expect to follow this up with a commit adding some sort of
simple selector on the image page.
As an aside, it should be noted, this only detects languages
if its in the first $wgSVGMetadataCutoff (256 kb). This is a
compromise to avoid OOM on huge SVG files.
Change-Id: I2a462270fe63eb3e3023419eddc8b06f5a617ab5
Temporarily disable loading entities in XMLReader when calling read()
with libxml_disable_entity_loader(true).
bug: 46859
Change-Id: I0b2ef270f15c7b4da17edee680bf7e2410919915
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
* 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
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
(Quite a few of these issues are my fault from 65c27ddeb1)
*All fields were starting as collapsed, which was not the intent of the code
*Animated field used non-existent messages, and displayed a value of "1" instead
of something meaningful to the user. Both (A)PNG and GIF handlers put
the animated status in the long description which feels more natural to me
so move the animated status to the long desc (long desc = subtitle under
the image on the description page).
*Use human readable file sizes in the long description instead of
total number of bytes. This bring it in line with the implementation
in the parent class.
*Correctly mark scripted SVG's as animated. Mostly a moot point
since we do not allow animated svgs past the upload checks
but for completeness and for people who totally
disable all upload verification.
(Note: This would miss event attributes (onclick, etc)
I didn't see much point in adding that since almost
always there will be a script tag)
Patchset 3: trailing whitespace (d'oh)
patchset 4: rebasing so jenkins is happy
Change-Id: Ic58efbf2bf1e4b14e3129e5bce9ea920d9804111
When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
--ta línea y las que están debajo serán ignoradas--
M includes/media/SVGMetadataExtractor.php
M tests/phpunit/includes/media/SVGMetadataExtractorTest.php
Mac OS X 10.5.8 comes with libxml 2.6.16, thus some methods of XMLReader
are not availabe (ex: readInnerXML()).
This patch, throw an error if the above method does not exist (only one
use in our code).
Since metadata can comes as string or an XML fragment, I have split the tests
to take care of the two usages and of the exception.
The previous fix (in r82307) only checked explicitly for a namespace given the 'svg' prefix; this fix use XML namespacing support on XMLReader to check for the actual namespace URI correctly.
Fixed up a test case (for RDF extraction) and added trimming on the whitespace.
Also added another test case file that doesn't use a namespace name on the root.
Add a new config variable $wgSVGMetadataCutoff (currently set to 256kb, chosen rather arbitrarily)
and only read that much of the svg file when finding metadata. In general:
*Most (non-crazy huge map) svgs aren't that big, so there'd be no change in general
*Almost all files have any relevent metadata (well except for when we look for animation tags) is at the begining of the file
before actual image data.
*At the end of the day, even if this does miss metadata in some files (which I really doubt it would), I'd consider that a better
situation then the current situation where it can take 10 minutes or have OOM to parse the likes of [[:File:Puerto_Rico_ecosystems_map-fr.svg]]
Also has parts of/parts are based on Hartman's patch from bugzilla in it.
Also changes how it recurses into child elements looking for animation, to do so only when neccesary.
Trims the results of reading values, because i was getting extra leading spaces when testing this.
Last of all, add a comment to the MediaHandler class about how the first parameter of MediaHandler::getMetadata is kind of useless.
(it confused me when I was doing this)
* Retrieve title and desc of SVG files
* Retrieve metadata in raw form (not displayed)
* Detect SVG animations using SVG animation elements (http://www.w3.org/TR/SVG/animate.html)
* SVG metadata is now stored and versioned.
Chosing not to provide fallback for these functions as they seem unused outside of SVG.php (per Google) and grep.
