Update/Create override classes of ContentHandler.
Soft-deprecate and remove method from Content and classes that override them.
Bug: T287158
Change-Id: Idfcfbfe1a196cd69a04ca357281d08bb3d097ce2
Also, we have well over 400 languages now, and RELEASE-NOTES
are updated accordingly.
Bug: T291899
Change-Id: I90877b5f0cde678537eed1a68e0a8fbdddb326ff
- Make it consistently return a StatusValue, as is expected by this
kind of methods.
- Omit the comment in the returned status, as it matches the one
that was passed as method parameter to undelete().
- Return a good status if there was nothing to undelete. Callers can
check the status value to determine if something was deleted.
The new format will make getRevisionStatus and getFileStatus
unnecessary, and will also make it impossible to distinguish between
file-related and revision-related errors. I don't think this is really
important (only SpecialUndelete uses the respective methods).
PageArchive is responsible for maintaining backwards compatibility with
the old format.
Bug: T290021
Change-Id: I51179fa7707b5fc44d2257cc927edc0bd798a4d9
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
Follows-up Ieaf04e0c289646dd5 which changed internal references to
bool(true) for 'debug' to the integer DEBUG_ constants, and introduced
a new debug=2 parameter.
In the refactor, I missed the setDebug() calls for
DerivativeResourceLoaderContext, which were still passing a boolean,
but more importantly were effectively passing debug=1 even if the
pageview carried debug=2. This isn't a problem yet in production since
debug=2 is currently identical in behaviour to debug=1.
The impact of this issue is mainly noticed through secondary CSS
requests. The URLs for primary stylesheets, and JS modules was already
forwarding the current "debug" version.
Test Plan:
* Open Main_Page?action=edit&debug=2
* Before this patch, e.g. on mediawiki.org today, secondary
stylesheet requests (part of a JS module) have debug=1.
For example "modules=jquery.makeCollapsible.styles&only=styles".
* After this, everything has debug=2 when the page view has debug=2.
Bug: T85805
Change-Id: Ia8fba4e30397bc5890033f13417b6739b0f83c38
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
$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
