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
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
