The addModuleScripts() methods were deprecated in 1.31 and 1.32,
these are now removed.
The getModuleScripts() are now deprecated as well, always returning
an empty array. To be removed in 1.34.
Depends on commits for bundled/wmf-deployed extensions that
remove the last few remaining callers to the deprecated functions
in: 3D, Collection, Flow, GlobalUserPage, and Wikibase.
Bug: T188689
Depends-On: If9f0bc6aef85117587fa1929f34f8861c8d80314
Depends-On: Ia8d41b97fbf6822f5f8f7ac889408acce1ac9a3a
Depends-On: I503b919739ea474ff33726815b0da55e2f7e2724
Depends-On: I236ef637fd03b810a46eb361e25067a037e9d183
Depends-On: I62e17779753b977a452cc0c9694947941e999cc3
Change-Id: I5a19b8f164ccf666485d2971202194b747f882df
Two bugs here:
* If the error array contains an entry using a Message object instead of
a string as the key, it'll blow up trying to do
`self::$blockMsgMap[$error[0]]`.
* If the error array contains a Message object not wrapped in an array,
it'll blow up trying to do `...(array)$error`.
Bug: T217382
Change-Id: I2a08e02bca0fb194416b3f2e6a1d6192d5c13cb2
The code in EditPage and SpecialMovepage does this primarily in web UI
code paths that aren't called by the API. EditPage also has a check in
the internal code path used by the API, but ApiEditPage runs its own
permissions check first and won't reach that code path.
Bug: T216245
Change-Id: I6263c8b60a24f3195dba583463f1ce4b004f82f5
When using ApiBase::errorArrayToStatus(), block info was added to
'blocked' errors. But when using dieStatus() with a Status object
returned by core MediaWiki code, block info was not being added.
Change-Id: I14887b6dd76d665055283945b956b2e26c521ed5
Depends-On: Ie3addf53ab5fabf1c24e1033b58e63927f4e21bf
Function Content::getNativeData() was deprecated. Replace with
calls to new function TextContent::getText() in most places.
Bug: T155582
Change-Id: I2bd508c72aac4faf474ba45ab1f92e2e8d2eb9be
If a deprecated parameter has a default value, or a deprecated value is
part of the default value for a parameter, don't give the client a
deprecation warning about it.
Bug: T215548
Change-Id: I980763e3d44fb1b7459c64b175fcaddf5fd44a13
This adds a UI for blocking namespaces to Special:Block
and a namespacerestrictions parameter to the block API.
The number of namespace restrictions in a single block
is not limited as page restrictions are.
The checkbox allowing the blocker to specify whether
the target can edit their own user page is normally
disabled for a partial block, but is re-enabled if
the block is to the user talk namespace.
If the config $wgBlockAllowsUTEdit is set to false, the
checkbox will not appear, and the target will not be
able to edit their own user talk page if they are
sitewide-blocked, namespace-blocked from the user talk
namespace, or page-blocked from their user talk page.
Bug: T204986
Change-Id: I9e231ad109d7285486ec332b26780339592b8df7
When batched deletions via the job queue were added in Ie800fb5a, the
way this was reported caused ApiDelete to report an error. Instead it
should report success with appropriate signaling to the client.
Bug: T212356
Change-Id: I1ef66277e988572c6720cf3e3cb36b18530746b4
If partial blocks are available but a sitewide block is being made,
$params['pagerestrictions'] is null and implode() raises a warning.
Since null casts to the empty array, it's easy enough to work around.
Also add a test hitting this case.
Change-Id: Id7e2559d7569031b7c1228adb0c0a14b3c1527c3
Ensure that errors encoding API results produce actionable log entries.
Part of the follow-up to T210550.
Change-Id: I6f311451e3b07b540f14352ce25af9d74a053d19
RevisionStore::getPreviousRevision() and ::getNextRevision() don't
handle being passed a RevisionArchiveRecord very well. Even if they
would, it's not clear whether the user wants to be comparing with the
next/previous deleted revision or the next/previous revision even if not
deleted. So let's just make it an error, at least for now.
Bug: T208929
Change-Id: I151019e336bda92aa4040ba4162eb2588c909652
The code for all uncaught exceptions will in the future be
"internal_api_error". If the client needs to know the class name for
some reason, it can check the new 'errorclass' data item on the error.
Change-Id: Ia9e32bbb8d17692203f4fbcee53a20e87be1776e
Validate them in ApiMessageTrait when the message is created, and again
in ApiMain before they're included in the header.
This also introduces an "api-warning" log channel, since "api" is too
spammy for real use, and converts a few existing things to use it.
Bug: T208926
Change-Id: Ib2d8bd4d4a5d58af76431835ba783c148de7792a
Depends-On: Iced44f2602d57eea9a2d15aee5b8c9a50092b49c
Depends-On: I5c2747f527c30ded7a614feb26f5777d901bd512
Depends-On: I9c9bd8f5309518fcbab7179fb71d209c005e5e64
This should reduce excess contention and lock timeouts.
Previously, it used a pre-commit hook which ran just before the
end of the DB transaction round.
Also removed unused User::incEditCountImmediate() method.
Bug: T202715
Depends-on: I6d239a5ea286afb10d9e317b2ee1436de60f7e4f
Depends-on: I0ad3d17107efc7b0e59f1dd54d5733cd1572a2b7
Change-Id: I0d6d7ddd91bbb21995142808248d162e05696d47
The ApiQueryBlocks and ApiQueryUserinfo endpoints will now return whether or not the block is
sitewide or partial. Partial block restrictions can be returned with ApiQueryBlocks.
Bug: T197141
Change-Id: I76eb4cac4dc989c621a00a39996faebd0eb9892c
Enforce partial blocks and display a slightly different block
notice depending on if the block is sitewide or not
Bug: T197117
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: I8a3635a4a04a33912eb139b7b13c4bd874183d31
Make the necessary UI changes to Special:Block in order to set/update
partial blocks.
Bug: T197109
Change-Id: Ib3067824b5dcbdd893ab1f165d169a35d0716cb2
Prior to I700edfa76, torelative=prev on the first revision of a page
would "diff" from an empty revision, and torelative=next on the latest
revision would diff to that same latest revision. People were depending
on that behavior, so restore it.
Bug: T203433
Change-Id: Ie81b58c196998a8047322740fe1d1fa44eff8526
T194585 raises a use case for callers to be able to know why an action
is not allowed. We can make that possible easily enough. The default
remains to return only a boolean.
This also deprecates inprop=readable in favor of intestactions=read,
since they both just return `$title->userCan( 'read', $user )`.
(ApiQueryInfoTest added by David Barratt)
Bug: T194585
Change-Id: Ib880f0605880eac776d816ea04e0c7ab9cfbaab1
Co-Authored-By: David Barratt <dbarratt@wikimedia.org>
MediaWiki uses a number of nonstandard codes which do not validate
according to the IANA language subtag registry. Some of them have
the wrong semantics entirely: MediaWiki's `sr-ec` variant maps to
BCP 47 `sr-EC` which is "Serbian as used in Ethiopia" (!).
Extend LanguageCode::bcp47() to map our nonstandard codes to valid
BCP 47 language codes. Export the mapping so that it can be used
in JavaScript's corresponding mw.language.bcp47() implementation
as well, and return the standard BCP 47 codes in the siteinfo
API.
Thanks to TheDJ (I10b4473c7e53f027812bbccf26bb47aec15fddfd) and
Fomafix (I93efc190714ba76247d30ba49fc21ae872fc3555) for previous
attempts at this!
Also removed a fixme for the name of 'Twi', dating back to 2004
(f59c3be23b) -- checking
tw.wikipedia.org it certainly appears that the autonym of 'Twi'
is correctly 'Twi'.
Tracking bugs for invalid language codes are T125073 and T145535.
Discussion of zh-XX => zh-HanX-XX mapping is at T198419.
This is a replay of an earlier merged patch,
8380f0173e, which had to be reverted
because it caused regressions in the Babel extension (T199941).
Bug: T34483
Bug: T106367
Bug: T120847
Depends-On: I27a5b8e45b34c6b57c1b612b11548001c88cd483
Change-Id: Iebbc604af21d7f2af9c1f1ab2574cb5f309bf6ed
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
Coverage is 100% except for one session-related bit that seems a bit
involved to test right now. It looks like it will be easier once
SessionManager becomes a service.
I removed the third parameter from the return value of
canonicalizeLoginData, since af37a4c7 made it always return true.
I also removed three lines of dead code from ApiLogin.php.
Change-Id: Ia0073eddd27c82827518e0031e3c313f83cfd7cc
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
The only thing missing is tests for the rawfm paths, which I don't
understand well enough to test easily.
Change-Id: I08779391798b9d2d5eeb7e19ec4764059336069c
