Extension Gadgets use a boolean value for $defaultOverride.
Also fix the return type for getOption and getDefaultOption.
This change is needed to pass the tests in
I255237574e76f1c0d92f376bc8cbb81f7cb4ed14.
Change-Id: I92ecaa9c14e5c8ba32d152a9e2246a2144b1c7da
This changes User::getActorId() to include the user name and id
when throwing an exception. This doesn't solve the problem
reported in T211450, but should allow the the probelmatic user
name to be identified.
Bug: T211450
Change-Id: Ie83ce6ad6b5ef18ea44a52e204f580cd9c992148
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
Drawing from comments associated with `User::newSystemUser` for
checking if a user is a system user, a new method, `User:isSystemUser`
is split out to avoid duplication elsewhere.
Bug: T237356
Change-Id: I73f25a10df2c28a69f612eb1db3e91b7125383d9
To avoid preference bloat, this preference is hidden unless the new
sysadmin config $wgSearchMatchRedirectPreference is set.
Bug: T235263
Change-Id: Ic16f53a4e6ddb6da071d63cd5da28d937d4692c8
Various maintenance scripts assume reserved usernames like
"MediaWiki default" exist, but since they're reserved
User::isUsableName() returns false and therefore the actor migration
created them as anonymous actors. Which would then prevent those
maintenance scripts from using User::newSystemUser() to ensure they
actually exist.
This adjusts User::newSystemUser() to be able to create users for
those anonymous actors.
This also adjusts uses of "MediaWiki default" in core to create it as a
system user.
Bug: T236444
Change-Id: I59a646df36ff9343cc43c05aa20b2b69b2ee124a
The method was soft-deprecated in 1.34. It's not used in any WMF
installed extensions or the tarball, so it can be hard deprecated.
Bug: T220191
Change-Id: I2f48d62a8dd3592918a6197168d31a1e08bd2a3e
The method was soft-deprecated in 1.34, all usages in
WMF installed extensions or tarball installation were removed.
Depends-On: Icb739a3fbf54f5926ca1b661a8707a043ebf09f1
Bug: T220191
Change-Id: I0ee797be35d5278bd081dd07c483e69d9cba6244
Add functionality that does not send password reset email to user accounts that turned on preference
that requires both username and email to be submitted in the PasswordReset form when only email is
provided.
Bug: T234401
Change-Id: I9bddc7073b8bcb52c4287b3d6c7343be29b717f2
Deprecate mBlock, mBlockedby and mHideName as public properties,
since they allow the user to be put into an inconsistent state.
These properties were previously used by now-deprecated hooks
(bf5464614b, af24fc1a7a) and tests.
Bug: T229035
Change-Id: Ia657eaf8b5e4a77ff9df84eb706de1030e17c3bd
This reverts commit 5f06efb318, which
reverted 9335363789, which makes
the deprecated property AbstractBlock::mReason private.
After 9335363789, AbstractBlock::mReason is obsolete, since the block
reason is now stored as a CommentStoreComment, AbstractBlock::reason.
Change-Id: Ica0a74be90383689ca8e4cfe6d0fb25c9a5942c5
This reverts commit 9335363789.
Reason for revert: It's full of code accessing AbstractBlock::mReason
out there, see [1]. Also, it was never hard deprecated. While that may
be acceptable under some circumstances, it's definitely not OK to remove
code when there are consumers around. I'd have fixed it right now without
reverting if it were a single repo, but there's just too many.
[1] - https://codesearch.wmflabs.org/search/?q=-%3EmReason&i=nope&files=&repos=
Change-Id: I8669f502b50cff89e28dada0f65fe2b130ae9b37
AbstractBlock::setReason now accepts a string, Message or
CommentStoreComment. The CommentStoreComment is accessed via
AbstractBlock::getReasonComment.
AbstractBlock::getReason returns the reason as a string, with
the language and format consistent with how block reasons were
built before this commit. This method is deprecated, since it
makes assumptions about the language and format needed. The
deprecated mReason property is no longer public.
Doing this (and T227005) will remove the implicit dependency of
BlockManager::getUserBlock on language, which causes a recursion
error if the block is checked before the user has loaded. It also
provides a mechanism for getting the block reason in a language
specified by the caller. (This does not apply to DatabaseBlock
reasons entered via the Special:Block form, which were not and
are still not translatable.)
This commit also updates authentication classes to return the
translated reason.
Bug: T227007
Change-Id: Iec36876e930dff96a256aebbdc39cbfb331c244e
These are almost only doc changes, with two exceptions:
1-In LinkHolderArray, int-alike array keys are now cast to int, to be uniform with what we do in other code paths
2-In ExtensionRegistration, changed a line to throw an Exception
immediately, instead of an ExtensionDependencyError. This is because the
latter takes an array with msg and type, but we were passing it a plain
string (and in fact the code was bugged).
Bug: T231636
Change-Id: I8b0ef50d279c2a87490dde6a467a4e22c0710afd
This was previously hardcoded from three places: 1) Upon viewing EditPage,
2) Upon viewing SpecialCreateAccount, 3) For any url if the user is
logged-in (User::loadFromSession/isLoggedIn).
== User::loadFromSession
Performing cookie blocks from here created a circular dependency because
Block may need the user language for localisation, which is determined by
asking the User object. This was previously worked around by using a
DeferredUpdate (T180050, T226777). Moving this logic explicitly to the
end of the pre-send cycle in MediaWiki::preOutputCommit breaks the cycle.
This is also where other request-specific handling resides already.
== Limited effect on unregistered users
When an unregistered user performs an edit, and gets blocked,
the cookie block is not applied until they open built-in editor
or CreateAccount page. This makes it more likely for a user's
IP to change meanwhile. Either intentionally, or simply due to
IPs varying naturally (e.g. between mobile locations, or when
going on/off WiFi). By applying it throughout sessioned page
views for unregistered users, it is more likely to get set.
Similar to what was already done for logged-in users.
This commit also makes the intent of not caching EditPage and
SpecialCreateAccount explicit. This was previously implicit
through nothing having called setCdnMaxage() and/or due to
Session::persist being checked for by OutputPage::sendCacheControl.
Bug: T233594
Change-Id: Icf5a00f9b41d31bb6d4742c049feca0039d0c9d9
Blocks are checked from the User object. Specifically,
User::getBlockedStatus instantiates a BlockManager and calls
BlockManager::getUserBlock. However, checking the block often depends
on knowing more about the state than the User should know. As a result,
the global user and request objects were passed into the block manager
on construction.
Whether the global request object should be passed into a service
constructor is still up for debate, so this moves the check for the
global state back to User::getBlockedStatus for now. (Note that it
reintroduces the problem of the User knowing more about state than it
should.)
This change also makes clearer the cases in which
BlockManager::getUserBlock is called from the User.
Different blocks may be sought, depending on the user and their
permissions. The user may be:
(1) The global user (and can be affected by IP blocks). The global
request object is needed for checking the IP address, the XFF
header and the cookies.
(2) The global user (and exempt from IP blocks). The global request
object is needed for checking the cookies.
(3) Another user (not the global user). No request object is available
or needed; just look for a block against the user account.
Cases #1 and #2 check whether the global user is blocked in practice;
the block may due to their user account being blocked or to an IP
address block or cookie block (or multiple of these). Case #3 simply
checks whether a user's account is blocked, and does not determine
whether the person using that account is affected in practice by any
IP address or cookie blocks.
Bug: T231919
Change-Id: I3f51fd3579514b83b567dfe20926df2f0930dc85
This was replaced by GetUserBlock in 7a5508573a.
Handlers in production were updated to use GetUserBlock in
I952aa7d40 and Ibbcd3a239.
Bug: T229035
Change-Id: I95f9fabc6e795243cfe0a1e8737ca6abfb865538
These callers just need to load some data from DB_MASTER.
Subsequent code needing that latest title data should also use the
required flags, rather than relying on flakey global cache state.
Change-Id: I53248ea4b5bf1cd953f956c41b8244831ec5ef04
This was replaced by GetUserBlock in 7a5508573a.
Handlers in production were updated to use GetUserBlock in
Ibbcd3a239.
Bug: T228948
Change-Id: I3e6da73e595e2bd6a96600fe2a6dc68a54d06a2e
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
And also update approximated counts, which for the most part are lower
than reported (hooray!)
Bug: T231636
Depends-On: Ica50297ec7c71a81ba2204f9763499da925067bd
Change-Id: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
