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
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
The startup module varies by skin, so it should be possible for
consumers of the ResourceLoaderGetConfigVars hook to know what
skin it being requested.
Bug: T186062
Change-Id: I97d6b4bc245bc64ff148c3665b46116b8a6be409
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
This hook is created specifically for I379e17c.
The purpose of this hook is to override UserGetRights hook and ensure
that the removed rights will not be reinserted by the other callbacks.
Change-Id: Id31b1f25f2eda012bd811f4b96aac525bc3251c4
This adds getSecondaryDataUpdates and getDeletionUpdates
to ContentHandler, and updates WikiPage and DerivedPageDataUpdates
to handle DataUpdates from all slots.
Bug: T194038
Bug: T194037
Change-Id: I75c96318f58a5cdda48484f7040ae41e6f42392a
Neither SpecialWatchlistFilters nor SpecialRecentChangesFilters are used in any
code known to Wikimedia code search. The related code to use these hooks was
only ever used within the MediaWiki repo.
Change-Id: Ib631d49d7b5835c665171dbad3e8a646b80827ef
Move logic for rendering a diff between two content objects out of
DifferenceEngine, into a new SlotDiffRenderer class. Make
DifferenceEngine use multiple SlotDiffRenderers, one per slot.
This separates the class tree for changing high-level diff properties
such as the header or the revision selection method (same as before:
subclass DifferenceEngine and override ContentHandler::getDiffEngineClass
or implement GetDifferenceEngine) and the one for changing the actual
diff rendering for a given content type (subclass SlotDiffRenderer and
override ContentHandler::getSlotDiffRenderer or implement
GetSlotDiffRenderer). To keep B/C, when SlotDiffRenderer is not overridden
for a given content type but DifferenceEngine is, that DifferenceEngine
will be used instead.
The weak point of the scheme is overriding the DifferenceEngine methods
passing control to the SlotDiffRenderers (the ones calling
getDifferenceEngines), without calling the parent. These are:
showDiffStyle, getDiffBody, getDiffBodyCacheKeyParams. Extensions doing
that will probably break in unpredictable ways (most likely, only
showing the main slot diff). Nothing in gerrit does it, at least.
A new GetSlotDiffRenderer hook is added to modify rendering for content
models not owned by the extension, much like how GetDifferenceEngine
works.
Also deprecates public access to mNewRev/mOldRev and creates public
getters instead. DifferenceEngine never supported external changes to
those properties, this just acknowledges it.
Bug: T194731
Change-Id: I2f8a9dbebd2290b7feafb20e2bb2a2693e18ba11
Depends-On: I04e885a33bfce5bccc807b9bcfe1eaa577a9fd47
Depends-On: I203d8895bf436b7fee53fe4718dede8a3b1768bc
This way the hook is able to consider what kind of DifferenceEngine
was created by default, or even wrap/decorate it.
Change-Id: Ibb6b1b087a2dda445be2b5e8c7518c7d169b5192
I think it's reasonable for link "colours" to depend on the page on
which they are shown. It seems similar to how self-links are handled.
The $colours variable is not cached, so title-specific link colours
will not "leak" to other titles.
Used in ProofreadPage in Ic910c2c33a6f1f8a70d9a122fbd2128428f29bd5.
Bug: T199288
Change-Id: I7378102a3e06544e9e695b255982c9bb0cfbf3a2
This allows AbuseFilter to add an extra link in the tool links section of
the subtitle on a history page
Co-authored-by: Matěj Suchánek
Bug: T28934
Change-Id: I2e0e9e92d3fc303135b0eb9acf06b5fd120178a5
Code from wikiHow codebase, where this hook is used by the following extensions:
* AlternateDomain -- used to remove certain links altogether and change the contents of other elements (e.g. <meta description="..." />)
* hooks (PageHooks) -- used to hide certain links for anons on noindexed pages to avoid leaking article info to Googlebot
* QADomain -- used to remove certain elements and correct <meta keywords="..." /> tags not to mention "wikiHow" if that string is present
* search (LSearch) -- used to remove canonical URL on Special:LSearch for SEO
Change-Id: I4a9ceb343bb5c0b4eb79e4589d36c3790938f8a9
wikiHow added a new hook called 'SpecialSearchPowerBoxOpts', which was passed only &$opts, so that the Finner extension can unset the $opts array. Enhancing the pre-existing hook is a better solution in this case.
Change-Id: I091cbdc78fc779144554d8420a95435b7048c407
* All Xml generation code has been removed.
* The LogEventsListGetExtraInputs hook now needs a form
descriptor array and not plain HTML.
See I37e0d3e81a46239750465b9299279fbbd7c7f87a.
* LogPager and LogEventList also take the $day parameter
for 'From date (and earlier)' and pass it to getDateCond
as well.
* Since FormOptions can't automatically extract the date
from the request this is being done manually in the
execute method of Special:Log using MWTimestamp.
Bug: T117737
Change-Id: Iba3c6aa5ac40dcdee0792c2d045b238b02d76521
The $baseRevId in WikiPage::doEditContent is used only to indicate what
revision an edit reverted to. It is not used to indicate the actual base
revision of an edit in any sense. Specifically, EditPage never sets it.
So, this change renames the parameter to $originalRevId to match $undidRevId.
It also renames PageUpdater::setBaseRevisionId to setOriginalRevisionId.
Further, this introduces a paramter to PageUpdater::hasEditConflict():
Before this change, PageUpdater::hasEditConflict() was based on the
revision set via PageUpdater::setBaseRevisionId(), assuming the semantics
of "base revision" used by EditPage. However, this is NOT how the $baseRevId
parameter in WikiPage works.
Bug: T197685
Change-Id: Ib78257d4d6ee7c4ec093d5706904c599b02c73e0
