The $forContent parameter was deprecated six years ago and looks
like nothing else is using it (verified via codeseach.wmflabs.org)
Change-Id: I7c6093a083845a40b82e39c91006a5a0b223eab6
It does not make sense for hook handler functions to *expect* the
Parser to be passed by reference. Hook handlers not only can't do
anything with it being a reference, they should *not* use it to
replace the Parser with another one.
This is an obsolete relict from PHP 3 (?), where objects got passed as a
cloned copy, which was very expensive.
Note we can not update the Hooks::run() calls as long as a single
hook handler still *expects* a reference.
Bug: T193950
Change-Id: I5f9a3f56faec0e90a2839c064844928c3b5c9751
It looks like the examples section on top of the hooks.txt file still
suggests to pass objects by reference. This is an obsolete relict from
PHP 4 and not needed any more.
Bug: T193950
Change-Id: I61bdc4a313401955943903918ff8167c2bea5aac
Changes:
* IP address/username is now a single label & input element combination
* Add page-specific styles in separate LESS file
* Remove no longer necessary CSS rule
Bug: T117736
Bug: T219238
Change-Id: I979078d8937898acae22bc28d5ed51da1d4ed627
It never makes sense to pass a (possibly different) Parser or PPFrame
object *back* as a reference. The & are a relic from very old PHP
versions that cloned all objects before passing them. This is not
needed any more.
Change-Id: I9fdb184cb41a61842819d44c9f07bd9cf435bb14
This was replaced by GetUserBlock in 7a5508573a.
Handlers in production were updated to use GetUserBlock in
I952aa7d40 and Ibbcd3a239.
Bug: T229035
Change-Id: I95f9fabc6e795243cfe0a1e8737ca6abfb865538
This was replaced by GetUserBlock in 7a5508573a.
Handlers in production were updated to use GetUserBlock in
Ibbcd3a239.
Bug: T228948
Change-Id: I3e6da73e595e2bd6a96600fe2a6dc68a54d06a2e
This allows extensions to add further links; the particular use case
in mind is for the AbuseFilter extension, but others may want this
too.
Bug: T231055
Change-Id: I671a0479e877e6c37606b688064cb9c893717709
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
