We formally deprecated running the parser with tidy disabled in 1.33, but
I missed a hard-deprecation on this code path.
Be careful not to spam the logs with deprecation warnings triggered by
(deprecated) API requests, though.
Change-Id: I10f64e76ec0c5aee8b26fc00bc11ebb0e39f961b
With this commit, the action=watch API accepts an 'expiry' parameter,
analagous to the expiry accepted by action=userrights, action=block,
etc.
Bug: T245078
Change-Id: If37a772253082529cb290027da87098c1e6bf98c
The basic idea is: The sequence `$var ?? 'default'` either uses the
value from the variable (or array element) if available, or falls back
to the default value. The resulting value is then used in the if()
condition.
if ( $var ?? true ) means the variable should default to true, if not
set.
This is mostly a style change.
In ApiEditPage the $params are impossible to not be set.
Change-Id: Id67b81744fa21fe22a2d2377259e426aab67c479
No classes extend ApiDelete, and this is essentially a breaking change
(previously accepted WikiPage or Article)
Update calls to WikiPage::doDeleteArticleReal to use the new signature
Bug: T247869
Bug: T247870
Change-Id: I48d9d8a2e1df92b81d8e477434c15e8ab3e90f3c
Wiki admins set wgInterwikiMagic=false when they do not want any
interwikis displayed in the sidebar as interlanguage links.
It is reasonable to expect they might add some interwikis
that looks like a language interwiki, linking to another wiki.
If that's done, MediaWiki incorrectly reports them as language interwiki,
which isn't correct.
Bug: T130381
Change-Id: Ie7c0ce43838c43392f144ab3a5ec9f847ec13182
These were clearly written with API users in mind. However, we
recently started using the 'assert' parameter in editing tools and
surfacing them to end-users (e.g. commit 7d6682195f encourages it),
and they don't make much sense in that context.
It's difficult to come up with a generic phrasing that works for any
tool making any action and also doesn't confuse API users too much…
but I tried.
Bug: T245327
Change-Id: I026e0e0b9ab77487385f0847d496b5e49517c73a
As well hard-deprecate RevisionStore::listRevisionSizes.
It was marked as @deprecated, but the release for the
deprecation was not specified. Let's say it's 1.35.
Additionally, in order to avoid temporary code duplication,
listRevisionSizes now uses getRevisionSizes and ignores the
database object injected into it. This is ok since we're
hard-deprecating the method and all the usages have been
removed.
Bug: T246284
Change-Id: Ifad1c25a0af892b88fce492b2d34c8cf71279b70
These are not configuration but business logic, similar to the
canonical names that are in NamespaceInfo.php, these must always
exist and cannot be altered or unset.
They were previously unconditionally assigned during all requests
in Setup.php and passed down as "site configuration".
Changes:
* Move them to MessagesEn.php where they can be cached and
processed the same way as other core-provided aliases.
Document and confirm with tests that this is a mergeable
attribute that follows the language chain.
* Remove the duplicated code in a few places that was reading
this variable + Language::getNamespaceAliases(), to instead
just call the latter and move the logic there, centralised,
and tested.
In doing so I noticed that these were applied in an
inconsistent order. Sometimes the config won, sometimes not.
There's no obvious right or wrong way here, but I've chosen
to standardise on the way that Language::getNamespaceIds() did
it, which is that config wins. This because that method seems
to be most widely used of the three (it decides how URLs and
titles are parsed), and thus the one I least want to change
the behaviour of.
* Document that $wgNamespaceAliases may only be used to
define (extra) aliases, it is and never was a way to access
the complete list of aliases.
Bug: T189966
Change-Id: Ibb14181aba8c1b509264ed40523e9ab4000fd71a
This shortens some lines below 120 characters when a tab is
counted as 4 characters (not that line lengths are currently
counted like that).
Bug: T243598
Change-Id: I828cd540268810bd56589885e38ad03f8bafc6f9
This adds a baserevid parameter for detecting edit conflicts, as an
alternative to the less precise basetimestamp parameter. This is
introduced for parity with and use by the new REST api.
Bug: T230843
Bug: T34037
Change-Id: Id7565018f66860b5c2ba688777508db1b88700ae
