Old hook PageContentSave only received the main slot of the article.
In order for extensions to intercept changes in all slots, they should
receive a RevisionSlots object with new content.
PageContentSave hook is still preserved for backward compatibility.
Note: parameters $iswatch and $section (from PageContentSave) are
not added into the new hook, because they are obsolete in the old hook.
Note: new hook also doesn't unnecessarily pass-by-reference (T193950),
which was an issue with the old hook.
Bug: T205982
Change-Id: I55455639c5ff6ccbf3917d85c1ab0dac847ec853
Ensure that the value returned is always also added to the cache, since
we (eventually) want to remove the hook's access to
$parser->mVarCache. Also don't allow monkeying with the value passed
as $magicWordId, even though it's a reference.
Code search:
https://codesearch.wmflabs.org/deployed/?q=ParserGetVariableValueSwitch&i=nope&files=&repos=
Bug: T236813
Depends-On: Ia12faefada7e4cf04f1a6b12b3ed1703bf28e437
Depends-On: Ia9e2e00c6b7d0e62cbe80c3b124165b691b1ff3d
Depends-On: I1e48fa47b8723958d543a69aaf9b62b872200dc5
Depends-On: If9a0885a8664c22473ade712364c2dd0a5c04e0b
Change-Id: I3d6b281f8e4e0bf68eefbf9767047527b4573b79
Deprecated since 1.32, and no longer used anywhere.
It is referenced in ApprovedRevs, but conditional on a MW < 1.35
context only.
Change-Id: I415927f198473ae3e795fac8c4811690424f167a
This is needed to migrate an extension (AutoWIGO2) that uses ArticleSave
to a version of MW after that hook was removed. The extension was using
ArticleSave to do its own PST processing, which probably doesn't work
with PageContentSave, and wasn't really the right way to do it in the
first place. Surprisingly, there were no useful hooks in PST or its
callers.
Change-Id: If1b3d7ea130a2b77609afe206eedc8445e1ab9f9
The interface generator script now flags any differences between the
argument list at the call site and the documented arguments. Resolve all
such differences.
* In AlternateEditPreview, $parserOutput is a reference, and a
WMF-deployed extension replaces it.
* In DeleteUnknownPreferences, fix missing "$" in &$where
* In LocalisationCacheRecache, document the unused parameter, as is the
convention elsewhere in the file.
* In NewRevisionFromEditComplete, make all callers pass a $tags
variable, and document the fact that there are multiple callers.
* In PageContentInsertComplete, document legacy references
* In PageContentSave, document the fact that $flags and $status are
references. I made them legacy references, since although replacement
will have an effect, no extension relies on this and it is not
documented on the Manual:Hooks page.
* In PageContentSaveComplete, document $wikiPage, $user, $flags and
$status as legacy references. Replacement of $status was broken
by If610c68f4912e89 (MW 1.32), but I confirmed that no extensions
in CodeSearch are currently affected.
* In ParserGetVariableValueSwitch, document $frame as a legacy reference
* In WatchArticleComplete and UnwatchArticleComplete, SpecialEditWatchlist
was passing $user by value where as the other callers were passing it
by reference. Passed by reference. It was already marked legacy.
Bug: T240307
Change-Id: I33f69ebdb5242982fd7986d9877959d2d33149b9
Includes the new $wgWatchlistExpiry feature flag.
Consumers of WatchedItem and WatchedItemStore have not been changed to
make use of expiries, this along with associated UI changes will be done
in a separate patch.
Bug: T245213
Change-Id: Ifff5e56e0222bb325cf796e0aa3d88825820d1fd
In hooks.txt, annotate all parameters that are references for legacy
reasons with [&] instead of &.
This will be the canonical source of this information. After T240307
is complete, assignment through the reference (replacement) will have no
effect. So if any parameters are incorrectly annotated with [&],
extensions will break.
These changes are final, since T240307 will make it impossible to change
the reference type of an existing hook. The only recourse will be add a
new hook without the reference.
Full review notes:
* FileDeleteComplete: A case of inappropriate non-object references
introduced by analogy: the local variables are not consulted after the
hook is called. CodeSearch reveals that handlers already use non-ref
params, presumably due to T193950
* BeforeInitialize: Replacing the title here would have some effect, but
it is fetched from the context and not written back, so the result would
be inconsistent. Inadvisable.
* InitializeArticleMaybeRedirect: $target and $article are certainly
replaceable, but not the request-sourced variables $title and $request.
The correct way to redirect is to use $target.
* IsTrustedProxy: $ip inappropriate scalar reference
* ResourceLoaderRegisterModules: The contract is pretty clear here,
replacement would be difficult
* ActionBeforeFormDisplay: replacement seems inadvisable; no handlers in
codesearch
* PageHistoryBeforeList: inadvisable, no callers replace
* UnwatchArticleComplete: $user was called with & but undocumented
* APIAfterExecute: seems safe from codesearch
* APIQueryGeneratorAfterExecute: no handlers
* User::mailPasswordInternal: handlers do not use ref params
* FetchChangesList: replacement would have no effect
* ParserFirstCallInit, ParserClearState, ParserBeforeStrip,
ParserAfterStrip, ParserAfterParse, ParserBeforeInternalParse,
InternalParseBeforeSanitize, InternalParseBeforeLinks, ParserBeforeTidy,
ParserAfterTidy, ParserGetVariableValueVarCache,
ParserGetVariableValueTs, ParserGetVariableValueSwitch,
BeforeParserrenderImageGallery: undocumented reference
* BeforeParserrenderImageGallery: replacement seems inadvisable after
mutation. No handlers.
* RevisionInsertComplete: undocumented reference
* SkinTemplateOutputPageBeforeExec: $tpl replacement would be
inadvisable after mutation. CodeSearch shows many callers, I haven't
reviewed them all, but a sampling shows $tpl->set() being the usual
pattern
* SpecialPageBeforeFormDisplay: CodeSearch confirms this is harmless
* BlockIp: did CodeSearch to confirm that neither variable is replaced
* SpecialMovepageAfterMove: did CodeSearch
* UnblockUser: no handlers
* UndeleteForm::showRevision: extensions/Video actually tries to replace
it, but forgot to declare the parameter as a reference. Filed T246408.
* ArticleEditUpdates: $editInfo is unused after the hook call
* PageContentSave: undocumented ref params. $mainContent is unused after
hook call.
* ImageBeforeProduceHTML: $dummy is unused after hook execution. The rest
could be altered
Bug: T193950
Change-Id: I6ddf54cb6812d2e292eca6d8e588364498c2fe73
There's no other way to detect parameters, since variable names are
often mentioned in the description prose, even at the start of a line.
Change-Id: Ie375ecffaae4efa268c5305ea9b1cc55a91cd813
Was deprecated in 1.28 and removed, so it need not be mentioned as
an alternative to `UploadVerifyFile`
Bug: T220656
Change-Id: Ic1c78a0216ca6f03099c1e8433297418f3d50172
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
