Introduced in 2015 via If83b062. Unfortunately the patch fails to mention
why the hook was introduced. A review comment asking for the missing
information was ignored.
The hook was introduced exclusively for the Cite extension, see I0e136f9.
The Cite change got reverted a few days later via I1a71854. As far as I
can tell the hook (oddly specific and underspecified anyway) was never
used again, neither for Cite nor for anything else.
Now unused: https://codesearch.wmflabs.org/search/?q=ParserAfterUnstrip
I suggest to just remove it with no deprecation phase.
My team is currently working on Cite, essentially turning it upside down.
I'm not aware of a need for this hook.
Change-Id: If68a88d7afff60385ff1e33fd13716b20d01a313
This will allow extensions/skins to alter the wiki pages that editors
can use to control styles
Bug: T237050
Change-Id: I329415b787136fcf9422a9deebfcd34f83b40f12
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
