These are almost only doc changes, with two exceptions:
1-In LinkHolderArray, int-alike array keys are now cast to int, to be uniform with what we do in other code paths
2-In ExtensionRegistration, changed a line to throw an Exception
immediately, instead of an ExtensionDependencyError. This is because the
latter takes an array with msg and type, but we were passing it a plain
string (and in fact the code was bugged).
Bug: T231636
Change-Id: I8b0ef50d279c2a87490dde6a467a4e22c0710afd
Deletion is only possible for files on the local wiki, so this is always
a LocalFile. The static self::doDelete already requires a LocalFile.
Caught by PhanTypeMismatchArgument, to be enabled with I34d65fe3ff191.
Change-Id: Iee0774340208b493b075085485343e05f922751c
It is already set in the parent class
To make phan happy, set the new type with a @property annotation
Change-Id: I47a83e3c4848b0a75284dc08c72df60b3d5dd19b
The 'upload links box' only contains a single link (or message),
so there's no need for it to be a list. This also adds a top-level
class to this box, for easier CSS/JS selecting.
Change-Id: I3967eea82dcd63a3e161daa13e49204e4d6dde97
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
This code is functionally identical, but less error prone (not so easy
to forget or mix these numerical indexes).
This patch happens to touch the Parser, which might be a bit scary. We
can remove this file from this patch if you prefer.
Change-Id: I8cbe3a9a6725d1c42b86e67678c1af15fbc5961a
We currently show SVGs in default languages unless overridden with
lang=... URL parameter (and we have UI for setting it). This change
makes it display thumbnails in wiki language, if translation is available.
Bug: T210814
Change-Id: Ieb0b5e9e27f45b71ef119bb3c1d3f2cd4d7100e5
Replace a fragile <div> wrapper with the robust
OutputPage::wrapWikiTextAsInterface() wrapper.
Bug: T205624
Change-Id: I0a1ba0da6af97f0233afdd8ba7202abed0998419
ImagePage::render() was calling parent::view() instead of
parent::render(), thus skipping Article::render() entirely.
Therefore the logic to disable section edit links (and also,
to add an 'X-Robots-Tag: noindex' header) was not being used.
This fixes T65891 and T21415 for pages in 'File:' namespace.
Bug: T206546
Change-Id: I36ae716c9a363ae29b7a785cc41430301250baba
This ensures that broken messages can't break the <div> wrapper and
that the output is tidy.
Bug: T205624
Change-Id: I2511adf593a13528e205a82d9fcdc8a524d0a95f
This change ensures that the output is tidy, and is necessary to support
future parsers which will not be able to produce untidy output.
Bug: T198214
Change-Id: I743f4185a03403f8d9b9db010ff1ee4e9342e062
This fixes 26 of the phan-taint-check warnings on MW core. Some
are outright fixed, others are false positives that were suppressed.
This really only covers some of the easy ones. There are still
314 warnings to go.
Change-Id: I30463bc3a09fd4324d190de8533f51784764dd3a
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
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.
It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.
* Replace a common pattern like `return $a < $b ? -1 : 1` with the
new operator (and similar patterns with the variables, the numbers
or the comparison inverted). Some of the uses were previously not
correctly handling the variables being equal; this is now
automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
$a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
when both variables are strings, but if any of the variables is not,
'strcmp()' converts it to a string before comparison, which could
give different results than '<=>', so changing this would require
careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
of the time (returns `1` if `$b` is lesser, and `0` if they are
equal or `$a` is lesser) but is erroneous.
Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
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
So that extensions wishing to modify ImagePage#openShowImage() that want
to preserve most of the existing functionality (at least in certain
contexts) do not have to copypaste these two methods over.
ImagePage#openShowImage() itself is ridiculously large and it's absurd
that to change a few things there you need to copy over the whole giant
block of code, but that's a separate matter.
Inspired by wikiHow's WikihowImagePage extension and their associated core
hacks to ImagePage.php, which hopefully won't be needed in the future.
Change-Id: Ic5e16acfc2cf4683154a60a3eaa9df69d30d03cb
Make the initial collapse of the metadata table not depend on
JavaScript. This eliminates the FOUC, and will also reduce JS
footprint once compat can be removed.
* Move the 'display: none;' styles from metadata.css to
filepage.css so that they are part of the base styles for
file pages (metadata.css is only for supporting metadata.js,
which is loaded dynamically).
* Apply "collapsed" class from the PHP side immediately,
instead of calling "addClass" in JavaScript.
* Restrict hide-styles to only apply under .client-js to make
sure the rows remain visible in no-js mode.
* Declare dependency between metadata.js and filepage.css.
This is just for documentation purposes, as they are both
already separately loaded on all file pages.
Change-Id: If22bf7acb47b59151dc3b0843a62507c100e548b
In preparation for trying out a CSS-only approach for the initial
collapse that doesn't cause the expanded view to flash first.
Bug: T182047
Change-Id: I42941ccb05d5525599a0209f0f33db9fe836580b
As a follow-up to T171338, the other uses of the message were ignored.
This change adds the protection log to these uses; that is, history and
image pages.
Bug: T174889
Change-Id: Ib9f22d6e06c372c4a32e77a08c846d768853bc21
See https://tools.ietf.org/html/bcp47#section-2.1.1
Also implement matching of systemLanguage attribs as
specified in the SVG spec
Note that librsvg that we use for rendering pngs of svg
files has a bug, and matches languages in the following
way instead of what is implemented in SVG::getMatchedLanguage()
public function getMatchedLanguage( $userPreferredLanguage, array $svgLanguages ) {
foreach ( $svgLanguages as $svgLang ) {
if ($svgLang == $userPreferredLanguage) {
return $svgLang;
}
$dashPosition = strpos( $userPreferredLanguage, '-' );
if ( $dashPosition !== false ) {
if (
strtolower( substr( $svgLang, 0, $dashPosition ) ) ==
strtolower( substr( $userPreferredLanguage, 0, $dashPosition ) )
) {
return $svgLang;
}
}
return null;
}
Bug: T154132
Change-Id: Ibff66a0844f0cecfae0260c6a7d20aeedc2849a2
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
This NS_FILE-specific redirect logic was introduced in 2008,
in 3c9536652a.
mTitle, as referenced to in the comments, no longer exists.
Article also no longer creates redirects in there, that’s now
in WikitextContent::fillParserOutput.
The original commit message describes that this was introduced
to be able to display redirects to foreign file repos. A lot
has changed in how that works since 2008, too :)
Back to the present: for redirects to foreign repos,
`$this->mPage->getFile()->getRedirected()` seems to always return
`null` (a placeholder object is created when the thing doesn’t
exist), so this this foreign repo-specific bit of code is bypassed
anyway. For local redirects, Article::view seems to be working just
fine.
By using Article::view, Categories used on file redirect pages
will now actually be displayed too.
And we can get rid of the otherwise no longer used Article::viewRedirect.
Bug: T29857
Change-Id: Icb02f3af32d10870f58d945cb06a84b3ba1305d3
This message is used as alt text for an image thumbnail, and so it
can't contain HTML tags anyway. This matches the 'imgmultipagenext'
message now. (This inconsistency has been present ever since the
feature was introduced in 2006: 7f7e79022bfd421e49084b089e74c7a16b77bc03.)
Due to using OutputPage::parse() instead of Message::parse(), an
incorrect `<div class="mw-parser-output">` wrapper was also being added.
Bug: T166508
Change-Id: I092887cc91e2c800685d4e55177aed814bb3fce9
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
