Several block-related hooks allow the user to be put into in a state
that is inconsistent with blocks that can actually be made:
* With UserIsHidden, User::mHideName can be set to true without there
being a block
* With UserIsBlockedFrom, a user can be blocked from editing a page
without there being a block
* With GetBlockedStatus, public block properties can be arbitrarily
set on a user
These problems are mostly theoretical, but mean that it is impossible to
make some basic assumptions, e.g. that a user who is blocked from a page
must have a block. The hooks are not widely used, and with a few changes
we can make them more robust so such assumptions can be made.
This patch:
* Ensures UserIsBlockedFrom is only called if there is a block. This
would be a breaking change if any extensions were using this to block
an unblocked user; the intended use case is clearly for extensions to
allow user talk page access to blocked users.
* Adds a new hook, GetUserBlockComplete, which passes the block for
modification. This should be used instead GetBlockedStatus and
UserIsHidden, which will be deprecated in the future.
* Allows the 'hideName' option to be passed into the AbstractBlock
constructor so that suppressing system blocks can be made.
Bug: T228948
Bug: T229035
Change-Id: I6f145335abeb16775b08e8c7c751a01f113281e3
This changes the examples in hooks.txt from using the old format of
manually entering additions into `wgHooks` to instead use the new
`"Hooks“: {}` object format.
Bug: T230397
Change-Id: I48a9986e4243eb933088d36b4bb095b345ab62fd
We are already tracking pageviews and with following change we should be able
to answer the following questions:
* Of the users who land on this page, what percentage of users actually
mute or unmute someone
* Of the users who mute a user, which option(s) did they check/uncheck in order
to mute/unmute the user
EventLogging Schema: https://meta.wikimedia.org/wiki/Schema:SpecialMuteSubmit
Bug: T224958
Change-Id: I655dbd999fd5d3d8f792c4f53b7cc502fe05afd5
The hook (SpecialMuteModifyFormFields) is used to append
the option to mute/unmute notifications from a specified user.
Special:Mute handles posting and saving the fields, the only
requirement is that the field name is the same as the property
that wants to be modified.
Currently there are only two notifications "blacklists":
* `email-blacklist` is directly handled in this page 'cause it is part of core.
* `echo-notifications-blacklist` is part of Echo, so this change is required
to support it. See I77b3ccfdce9b501e
Bug: T220163
Change-Id: I2b3eee0802cb086091f35ecce13ae77a8e7d518d
No longer allow hook functions to prevent message blobs from being
purged. Pass in an always-true variable for backwards compatibility,
which is then ignored.
Change-Id: I27ac9599711f2f0df2514a3934270af0ce03da7f
And start indicating that hooks relying on this data might become
unreliable as this data is only populated by SearchDatabase search
engines.
This information was only populated by SearchDatabase implementations
and due to bad initial design of SearchResult[Set] (now fixed) it forced
users of these classes to carry this information for the sole purpose of
highlighting.
Because SearchEngine can now own their SearchResult[Set] implementations
nothing that is engine specific should be exposed outside of these
specific implementations.
If there are some logic that still requires access to such list of terms
they should be made engine specific by guarding their code against
instanceof SqlSearchResult.
Change-Id: I38b82c5e4c35309ee447edc3ded60ca6a18b247a
Depends-On: I53fe37c65c7940f696c1e184125e01e592a976e4
1. FSFile::getPropsFromPath() is not used by any code any more.
https://codesearch.wmflabs.org/search/?q=FSFile%3A%3AgetPropsFromPath&i=1
The only remaining usage is in one test. We might as well remove the
function.
2. The $props array is passed to the hook for convenience, in case all
the file properties are already available. Fetching them from a file on
disc can be an expensive operation, and should be avoided if the
information is already available. But the caller does not guarantee this
is set. Other callees already know this can be a falsy value, notably
LocalFile::upload().
Change-Id: I43724d18467b6fb68a963b2206332cf553c81b2c
This is to avoid annoying fatal errors when someone annotated their
hook handler to only expect Language objects, but that expectation
is violated due to this code possibly passing StubUserLang to hooks,
some of which may also assign it to $pageLang.
Even with this in place, it is probably a good idea for hook handlers
to refrain from type hinting parameters that are passed by reference
because their types cannot be guaranteed.
Bug: T214358
Change-Id: I88405a8de4b13675eb5a9d11e9ddc87e20a85fb4
The generated links are now always known links.
All users of the hook 'SkinEditSectionLinks' in extensions set
'options' => [ 'noclasses', 'known' ]
5f48eb9acd/TinyMCE.hooks.php (291)857c1bd3d1/includes/VisualEditorHooks.php (617)
This change makes it easier to migrate to LinkRenderer in
Ifc170abc958add28a2fe08aa0c44af83c6f7cad8 without legacy options.
Change-Id: Ia5d151b81dabce9560045b45886f2c77abf975da
MWNamespace::clearCaches() has been removed entirely, along with the
$rebuild parameter to MWNamespace::getCanonicalNamespaces(). The rest of
MWNamespace is deprecated.
Diff best viewed with -C1 so git notices that NamespaceInfo is a copy of
MWNamespace.
Depends-On: Icb7a4a2a5d19fb1f2453b4b57a5271196b0e316d
Depends-On: Ib3c914fc99394e4876ac9fe27317a1eafa2ff69e
Change-Id: I1a03d4e146f5414ae73c7d1a5807c873323e8abc
This will allow the OAuth extension to subscribe to this hook and add an
“OAuth CID: $consumerId” tag to patrols made via OAuth.
Bug: T219655
Change-Id: Ie5e6f820bbf399ec639e715afd908f78bf5c8e9a
T110209 caused maintenance scripts to fail on unknown parameters,
which is normally desirable. However, some extensions (notably
SemanticMediaWiki) need to support additional params and had no
way to add them to the list of expected parameters. It will
now be possible them to update.php via a new hook:
MaintenanceUpdateAddParams.
Bug: T213893
Change-Id: Ia40949ccb2f32090f21e0f3f7e5b9c4aef322330
This hook is required by extensions like MobileFrontend to tag
log entries when actions are performed on the mobile web.
There is a possibility to tag log entries by using
'RecentChange_save' hook, but that works only when the log entry
is published to 'rc' or 'rcandudp'. This means, that tagged log
will appear also on the Special:RecentChanges page which is something
what extensions like 'Thanks' wants to avoid.
In the future we should avoid using 'RecentChange_save' as an
indirect way to tag log entries, and use the
'ManualLogEntryBeforePublish' hook instead.
To cover ourselves in the future, instead of passing &$tags only,
we pass the $this (the log entry object) so extensions can perform
additional checks before using setTags().
Bug: T215675
Change-Id: I747eded4bc5406cd5d4676fc93b0bb55c99f9a4d
Both calling fixUrlQueryArgs, which handle the array case
Also improve hooks docs for the similar functions getLinkUrl/getLocalUrl
Change-Id: I77df39711c7d6b2ee0a3709a6bdaf9cde6a616c6
Clarify that the type of second parameter that is being passed
to the hooks can be anything because one hook can change it and
then it is passed to another hook without the hook caller having
possibility to check or modify the value.
Clarify that hooks should only return Language objects.
Rename $wgLang to $userLang in the hook parameter documentation to
avoid false posivite matches for the global.
Fix some typos, use Title::inNamespace and add a test assertion.
Also, the $content parameter is unused by all implementations of
this method, and on quick look never passed by any caller. I kept
it for now, however.
Bug: T214358
Change-Id: Iae49d2998c2b762565d232c0337d84d43a4a900c
It was still looking for wfRunHooks, which no longer exists
as of MediaWiki 1.32.
After this, it is now able to find one bad hook:
> Unclear hook calls:
> - Hooks::run( $action . 'ArticleComplete', [ .. ] ); # SpecialEditWatchlist
Also, remove the matching of wfRunHooks generally, given it no
longer exists. And also remove the historic notes from hooks.txt.
Change-Id: I4ac52ed75fb99d7775d4b4755e3f0871003d70a8
Authentication audit logs should indicate whether a login is via the
normal password or a bot password (and which one). For failed logins
it could be included in the error message, and it usually is, but
for successful ones there is no message, so we'll send the app ID as
a new AuthManagerLoginAuthenticateAudit parameter.
Bug: T194338
Change-Id: I8aab48177b81a8e80dae118e6476a8f6a32089f1
Depends-On: Id482d2e2205960a0facd334e456d3a23bcad0ece
So that using this hook it's possible to prevent the move, also
providing some more context.
Also, clean error message: instead of going with "you do not have
permission blah blah" for *every* kind of error, use it only when the
error is actually about permissions, and use a generic message
otherwise.
Bug: T208907
Change-Id: I4733724075b7514e9db59e7be772d9409aa9da87
AbortAutoAccount, AbortNewAccount, AbortLogin, LoginUserMigrated,
UserCreateForm, and UserLoginForm are all unused in Wikimedia
production and rare in other extensions.
This also scraps the FakeAuthTemplate and LoginForm classes and
the occasional remainig references thereto.
Bug: T193755
Change-Id: I24d6fa963f402d4311fa00fc11536a37ee3bd31e
The following deprecated methods, intended for overriding by extensions,
are no longer called and are hard deprecated.
* ApiBase::getDescription() (deprecated in 1.25)
* ApiBase::getParamDescription() (deprecated in 1.25)
* ApiBase::getExamples() (deprecated in 1.25)
* ApiBase::getDescriptionMessage() (deprecated in 1.30)
Also, the 'APIGetDescription' and 'APIGetParamDescription' hooks have
been removed, as their only use was to allow extensions to override
values returned by getDescription() and getParamDescription(),
respectively.
Change-Id: I486c4ccab4eca6a85cb17c30dbb2439876123ba1
