* Correct the documentation of UploadBase::verifyUpload()
to clarify that it returns an array in all cases, and
document possible keys.
* Change the type hint of verification methods that may return
a boolean or a status array depending on the outcome of the
verification from 'mixed' to 'array|bool'.
Change-Id: I39d13db457104b02fc47a77fb6bfab05b2cbdcb6
These are reported by phan as PhanTypeMismatchArgumentNullableInternal
when null_casts_as_any_type is disabled.
Change-Id: I85076ee31c1bfc59a19600e84da0d915e425890a
File objects can contain closures which can't be serialized.
Instead, add makeWarningsSerializable(), which converts the warnings
to a serializable array. Make ApiUpload::transformWarnings() act on this
serializable array instead. For consistency, ApiUpload::getApiWarnings()
also needs to convert the result of checkWarnings() before transforming
it.
Bug: T228749
Change-Id: I8236aaf3683f93a03a5505803f4638e022cf6d85
This is only triggered for chunked uploads and does not need anything
more special the local objectcache table.
Also add comments and fix numerous IDEA warnings.
Bug: T227376
Change-Id: Ia61855293a265306c5a27a9dfc0139c4d0b04c4f
These global functions were deprecated in 1.34 and services made
available to replace them. See services below;
* wfFindFile() - MediaWikiServices::getInstance()->getRepoGroup()->findFile()
* wfLocalFind() - MediaWikiServices::getInstance()->getRepoGroup()->getLocalRepo()->newFile()
NOTES:
* wfFindFile() and wfLocalFind() usages in tests have been ignored
in this change per @Timo's comments about state of objects.
* includes/upload/UploadBase.php also maintained for now as it causes
some failures I don't fully understand, will investigate and handle
it in a follow up patch.
* Also, includes/MovePage.php
Change-Id: I9437494de003f40fbe591321da7b42d16bb732d6
Allows uploaded files to include some HTML tag strings that were
previously forbidden in the first 1k or so of the file:
* <a href
* <img
* <pre
* <table
* <title
They are now allowed as long as the IE MIME type detection heuristic
would not change their types. This should reduce the number of false
positive checks in JPEGs with EXIF data with links.
Also deprecates $wgAllowTitlesInSVG and allows it by default.
This should still protect against malformed PNG attacks on old IE
versions, though false positive checks are conceivable on PNG files
containing comments very close to the beginning of the file.
Adds $wgVerifyMimeTypeIE config var to allow disabling the IE checks
entirely, if desired, but leaves it in place by default. These are
more conservative than the checks that were removed.
Added test cases for the old IE5/6 bug and the particular sort of
JPEG metadata that struck false positives previously.
Bug: T27707
Change-Id: I66642a74fce1a1894cad67d62b0da61020db469a
There is like a billion of these in our core codebase. I would love to
update them all. But I don't have the time, at least not to do them all
at once.
TL;DR: It's an improvement. :-)
Change-Id: I0a9c51bdcf0f261f971586bb8703f418324b0f98
The filter attribute will often have things like filter="url( #foo )"
These local to the file filters in svgs should be fine (We already
disallow non-local xlink:href attributes on <filter> elements). In
fact, users can already do the exact same thing by doing:
style="filter: url( #foo )"
Bug: 67044
Change-Id: Ib25328c160c0d5ea7e01dc84616b76e1b9dcd0eb
This was spotted when running tests on Travis (PHP 7.3 nighly, trusty).
Two expressions inside preg_replace() contained non-escaped "-" inside [],
where this "-" meant an actual "-" character.
The warning is because "-" has special meaning inside [] ("a-z" for range),
and things like [\w-.] are considered "invalid range".
Solution is to escape "-" like this: [\w\-.]
Change-Id: I41cc217081f00f54d957b6d8052ee209412f5ff6
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
file_get_contents() started supporting a negative offset in 7.1+. But
we really just want to start with 0.
Also fix the order of arguments to assertSame() so that the expected
value is first.
Bug: T182366
Change-Id: I84c92652de5b51a43f6e2b58cd235d2889093453
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
* Remove some creation dates, they are not protected by GPL
* Remove duplicate @defgroup API
* Remove @ingroup from some @file doc comments on class files. It is not
useful to list class files alongside classes in the doxygen module menu.
Add @ingroup to some more class files that had @ingroup on their file,
that was probably the author's intent.
* In PackedOverlayImageGallery, use the file comment as a class comment
* Don't put @defgroup and @file in the same comment. @defgroup makes the
whole doc comment describe the group.
* Instead of putting AnsiTermColorer in two groups, use hierarchical
groups.
Change-Id: If54f6e0b2bc1ea6de42045885cf836ee67b8e961
Previously warnings about the sha1 of an uploaded file being
the same as an existing file were stripped if the existing
file was in local storage - this was to avoid duplicate
warnings if a file with the same name had already been found
and had the same content. Now the warning is only stripped
for local files with the same name as the uploaded file.
Bug: T180691
Change-Id: I455df30085c05320dca976b9f7f8fb711a083271
In some cases, the error messages have changed slightly, mostly because
of capitalisation & punctuation.
In a few other cases (mainly UploadStashNotLoggedInException), the content
has also slightly changed (removed mention of the __METHOD__ it occurred in)
Bug: T178291
Change-Id: I184067f2d7fe0a0a2df1114d2525fd9ab95b6c86
