PageProps has been converted into a service with dependency injection.
PageProps::getInstance() relies on global state and thus should be
avoided.
Bug: T289544
Change-Id: Iab3e94059cb6d2d11950ae870a1713f4b3a738fb
Always null, and no longer used. It was deprecated in favour of
wgCommentCodePointLimit which should be used instead.
Originally added in 2018 for T185948 as 255 or null, depending on
$wgCommentTableSchemaMigrationStage. In 2019, (I1479c73774e, T166733),
the comment migration was removed and the variable became always null,
and in change I876b02f45fc all remaining uses were removed in favour
of wgCommentCodePointLimit.
Bug: T291730
Bug: T227047
Change-Id: I0d48985026c96b9a5734a6409c88dc9cd6b2ae8a
PHPUnit 8.5.21 no longer converts deprecations to exceptions by default.
However, we rely on such conversions in our tests, otherwise there are
failures:
Failed asserting that exception of type "PHPUnit\Framework\Error\Deprecated" is thrown.
The upstream change is:
fac02620f6
Bug: T291731
Co-Authored-byː Antoine Musso <hashar@free.fr>
Change-Id: Ifacf26905a7fa24ea3aafad79e012ddfb0a797bb
$wgShellLocale was a flawed solution to the problem of locale
dependence. MediaWiki has its own concept of locale (the Language
hierarchy) and any kind of dependence on the server's libc locale is
incorrect and harmful, leading to bugs. Developers have an expectation
that functions like strtolower() will work in a certain way, and
respecting the locale set in the environment at install time violates
this expectation.
The problems with using C as a locale, which led to $wgShellLocale, are:
* escapeshellarg() will strip non-ASCII characters. This can be worked
around by not using it. The security vulnerability it was trying to
fix can be prevented in another way.
* Shell commands like rsvg will fail to correctly interpret UTF-8
arguments. This is the reason for the putenv(). On Linux, this can
be fixed by using C.UTF-8, which we didn't know at the time. On
Windows, the problem is not relevant (there are unrelated issues
with UTF-8 arguments).
Bug: T291234
Change-Id: Ib5ac0e7bc720dcc094303a358ee1c7bbdcfc6447
It is causing build failures as follows:
Running "stylelint:src" (stylelint) task
resources/src/mediawiki.special.preferences.styles.ooui.less
33:2 ✖ Needless disable for "plugin/no-unsupported-browser-features" --report-needless-disables
35:2 ✖ Needless disable for "plugin/no-unsupported-browser-features" --report-needless-disables
48:2 ✖ Needless disable for "plugin/no-unsupported-browser-features" --report-needless-disables
I don't know why or how they became needless.
Change-Id: I14d9fdcc97b260b1fd67e67349214c7947733324
Remove check for window.JSON, redundant to check for es5
strict mode.
Remove check for window.addEventListener, we also check for
querySelector which is a newer part of the same API.
Bug: T290293
Change-Id: I95e62c7c1ed8f98f9df9e94fef86dda9aa77326b
If $wgMaxImageArea is false, MediaWiki will no longer check if the image
fits within that area before trying to scale it. Extensions can still
use the BitmapHandlerCheckImageArea hook to override it.
This is primarily useful when using an external scaler like Wikimedia
does with Thumbor, which decides whether it can scale images by using a
timeout rather than based on size.
Codesearch indicates that the only extension checking this setting is
PagedTiffHandler, which will be updated in Iefa67321d07f7.
Bug: T291014
Depends-On: Iefa67321d07f79d982388231e02e87e2f18aed40
Change-Id: Id10173bbddb32bc70e036f426369cfbea52cecf4
- Add Skin::getOptions and Skin::getPortletLinkOptions, which are used
to provide skin options to mw.util.
- Add SkinFactory::getSkinOptions, which is used by
Skin::getPortletLinkOptions.
Depends-On: Ib23360e3439abc828404c1de8e0906915ee7d8b6
Bug: T289163
Change-Id: I801e7d583cb0b0c7da51f4da503268be736bb60c
