These three classes:
- TitleArray
- TitleArrayFromResult
- TitleFactory
We need to move these and the rest of files under title/ to Title/ (and
namespace them) but the patch will become way too big given that Title class is
also one of them.
Bug: T321882
Change-Id: Iac1688172ee457348a08a470c86e047571feb8e0
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
PHP 8.1 will give us "first class callables" that look like e.g.
$result = array_map( $this->fn(...), $array );
For now we can use
$result = array_map( [ $this, 'fn' ], $array );
Change-Id: I7278c80c075d162da73aa45af1b6578310ce0624
Defer to the TitleDef type definition for page titles to validate values
passed to the pagerestrictions parameter.
Bug: T279689
Change-Id: Ia2e116d1bc476b178d85a6331dec17d7a8df74ba
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
I believe it does not make sense to go on with peripheral action when
the primary action did not succeed.
If the blocker decides to attempt the block again, they can also decide
whether to add watch or not at that time.
Change-Id: I64880ce254e33378642bb9f1952c88ce490ef490
In SpecialBlock, ignore restrictions if the 'sitewide' radio was
selected. In ApiBlock, ignore restrictions if the 'partial' parameter
was falsey.
In both cases, ignoring restrictions means not passing them to
BlockUser.
This restores the behaviour prior to a656d03597, that a block is
sitewide unless it is marked as partial, even if restrictions options
are set.
Bug: T189073
Change-Id: I4d2e08b744b9d59909ce24cc5f167b676478970d
Pass 'partial' parameter from ApiBlock.
Pass 'DisableEmail' parameter from SpecialBlock only after confirming
it is set.
Follow-up to a656d03597
Bug: T189073
Change-Id: I5acbb1c5d49b216bb235936cd479829128beac77
Rather than having to do DatabaseBlock calls directly,
and then ManualLogEntry calls to facilitate logging,
let's create a BlockUser service, capable of blocking users
and logging, optionally with permission checking.
This should make blocking users easier for developers,
for instance, AbuseFilter or CheckUser can easily
benefit from this commit.
Bug: T189073
Change-Id: Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab
Refactor this method to make clearer that it returns the return value
of AbstractBlock::parseTarget and does nothing additional when called
without a WebRequest.
Update callers that do that to call parseTarget directly instead.
SpecialBlock::getTargetAndType (added in 97e2c97578) predates
AbstractBlock::parseTarget (added in f64f960d9a). The callers being
updated here called getTargetAndType since before parseTarget was
available.
Bug: T250940
Change-Id: I366e1076b10ab7c2dc4bb04920908b3286b77b73
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
$wgBlockCIDRLimit states how large rangeblocks are allowed to be for IPv4
and IPv6. The API now calls SpecialBlock::validateTarget() to perform
that validation step.
As a minor thing, SpecialBlock::checkUnblockSelf() is now called twice by
the API, but that can probably be cleaned up at another time.
Tests included.
Bug: T199540
Change-Id: Ic7d60240d9ebd9580c0eb3b41e4befceab69bd81
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
Fixes unintended breaking change made by I84ed21641c44b2f65ebe.
ApiQueryUserInfo::getBlockInfo() is restoed as a hard deprecated stub.
This renames the method in the new ApiBlockInfoTrait to
getBlockDetails.
Depends-On: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
Change-Id: If47a93878f87d69800e5f305404c22528dac5e94
ApiBase directly uses this method causing a cyclic dependency between
ApiBase and ApiQueryUserInfo
Change-Id: I84ed21641c44b2f65ebe1980b0893d1846db3b34
The method User::isBlocked() attempts to answer two questions:
(1) Does the user have a block?
(2) Is the user prevented from performing this action?
The method can answer #1, but it cannot answer #2. Since User::getBlock() can
also answer #1, this method is redundant. The method cannot answer #2 because
there is not enough context in order to answer that question.
If access is being checked against a Title object, all access checks can be
performed with PermissionManager:userCan() which will also check the user's
blocks.
If performing all access checks is not desirable, using
PermissionManager::isBlockedFrom() is also acceptable for only checking if the
user is blocked. This method does *not* determine if the action is allowed,
only that the user's block applies to that Title.
If access is being checked without an existing Title, User::getBlock() can be
used to get the user's block. Then Block::appliesToRight() can be used to
determine if the block applies explicitly to a right (or returns null if
it is unknown or false if explicitly allowed). If the user is creating a new
Title, but the text of the title is not yet known (as in the case of Wikibase),
access should be checked with Block::appliesToNamespace().
Bug: T209004
Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
Use getters and setters for $mReason, $mTimestamp, $mExpiry and
$mHideName; use Block::getType to check if a block is an autoblock
instead of checking $mAuto; no change needed for $mParentBlockId,
which is not accessed externally.
Change-Id: I767ed44ce4c2e21f53962d75fb86891add2282f6
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
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
Make the necessary UI changes to Special:Block in order to set/update
partial blocks.
Bug: T197109
Change-Id: Ib3067824b5dcbdd893ab1f165d169a35d0716cb2
The code coverage tool still reports that line 50 ("$status,") is not
covered, but this is just a parameter to a function that is in fact
called and does show up as covered, so I'm pretty sure it's a bug.
I replaced a couple of sanity checks that reported "incomplete" on
failure with actual assertions so that the test would fail properly if
the sanity check failed.
The testing could still probably be expanded considerably.
Change-Id: Ib6ba7227af23bcb50c7e3bafb0b51395e8acf03f
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
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
The current username validation lets any invalid username through, on
the assumption that it's an IP address. We can do better: call the
backend to get the actual type and target, and reject anything with
TYPE_USER where the actual input name is invalid (regardless of
underlying mangling for stuff like T31797).
Bug: T183211
Change-Id: I676642eee1222447df22a1c32b24f55e6273bcec
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
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: I49e2a10350a328a8572fcedd44012751a29e1068
Adds support for tagging log entries for the block, import,
managetags, and move API modules, using a 'tags' parameter.
Bug: T97720
Change-Id: I9d75d2cece317a7704c4bc6d734ad3cafe24544e
This allows for removing $wgContLang from many API modules where it was
only used to call $wgContLang->formatExpiry() in a way in which the
results don't actually depend on the language.
Change-Id: Ib0f25f288b9b87d2e4131297c552e5971696db87
Add feature to block/unblock users by their ID. For this,a new
parameter `userid` is added to block & unblock API request.
Bug: T34496
Change-Id: I084a4e275cd937053c505cd388a365b316990ece
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
