wiki.techinc.nl/docs/hooks.txt

4067 lines
179 KiB
Text
Raw Normal View History

hooks.txt
This document describes how event hooks work in MediaWiki; how to add hooks for
an event; and how to run hooks for an event.
==Glossary==
event
Something that happens with the wiki. For example: a user logs in. A wiki
page is saved. A wiki page is deleted. Often there are two events
associated with a single action: one before the code is run to make the
event happen, and one after. Each event has a name, preferably in
CamelCase. For example, 'UserLogin', 'PageContentSave',
'PageContentSaveComplete', 'ArticleDelete'.
hook
A clump of code and data that should be run when an event happens. This can
be either a function and a chunk of data, or an object and a method.
hook function
The function part of a hook.
==Rationale==
Hooks allow us to decouple optionally-run code from code that is run for
everyone. It allows MediaWiki hackers, third-party developers and local
administrators to define code that will be run at certain points in the mainline
code, and to modify the data run by that mainline code. Hooks can keep mainline
code simple, and make it easier to write extensions. Hooks are a principled
alternative to local patches.
Consider, for example, two options in MediaWiki. One reverses the order of a
title before displaying the article; the other converts the title to all
uppercase letters. Currently, in MediaWiki code, we would handle this as follows
(note: not real code, here):
function showAnArticle( $article ) {
2007-06-18 15:34:04 +00:00
global $wgReverseTitle, $wgCapitalizeTitle;
if ( $wgReverseTitle ) {
wfReverseTitle( $article );
2007-06-18 15:34:04 +00:00
}
if ( $wgCapitalizeTitle ) {
wfCapitalizeTitle( $article );
2007-06-18 15:34:04 +00:00
}
# code to actually show the article goes here
}
An extension writer, or a local admin, will often add custom code to the
function -- with or without a global variable. For example, someone wanting
email notification when an article is shown may add:
function showAnArticle( $article ) {
global $wgReverseTitle, $wgCapitalizeTitle, $wgNotifyArticle;
if ( $wgReverseTitle ) {
wfReverseTitle( $article );
}
if ( $wgCapitalizeTitle ) {
wfCapitalizeTitle( $article );
}
# code to actually show the article goes here
if ( $wgNotifyArticle ) {
wfNotifyArticleShow( $article );
}
}
Using a hook-running strategy, we can avoid having all this option-specific
stuff in our mainline code. Using hooks, the function becomes:
function showAnArticle( $article ) {
if ( Hooks::run( 'ArticleShow', [ $article ] ) ) {
# code to actually show the article goes here
Hooks::run( 'ArticleShowComplete', [ $article ] );
}
}
We've cleaned up the code here by removing clumps of weird, infrequently used
code and moving them off somewhere else. It's much easier for someone working
with this code to see what's _really_ going on, and make changes or fix bugs.
In addition, we can take all the code that deals with the little-used
title-reversing options (say) and put it in one place. Instead of having little
title-reversing if-blocks spread all over the codebase in showAnArticle,
deleteAnArticle, exportArticle, etc., we can concentrate it all in an extension
file:
function onArticleShow( $article ) {
# ...
}
function onArticleDelete( $article ) {
# ...
}
function onArticleExport( $article ) {
# ...
}
General practice is to have a dedicated file for functions activated by hooks,
which functions named 'onHookName'. In the example above, the file
'ReverseHooks.php' includes the functions that should be activated by the
'ArticleShow', 'ArticleDelete', and 'ArticleExport' hooks. The 'extension.json'
file with the extension's registration just has to add its hook functions
to the appropriate events:
"Hooks": {
"ArticleShow": "ReverseHooks:onArticleShow",
"ArticleDelete": "ReverseHooks::onArticleDelete",
"ArticleExport": "ReverseHooks::onArticleExport"
}
Having all this code related to the title-reversion option in one place means
that it's easier to read and understand; you don't have to do a grep-find to see
where the $wgReverseTitle variable is used, say.
If the code is well enough isolated, it can even be excluded when not used --
making for some slight savings in memory and load-up performance at runtime.
Admins who want to have all the reversed titles can add:
require_once 'extensions/ReverseTitle.php';
...to their LocalSettings.php file; those of us who don't want or need it can
just leave it out.
The extensions don't even have to be shipped with MediaWiki; they could be
provided by a third-party developer or written by the admin him/herself.
==Writing hooks==
A hook is a chunk of code run at some particular event. It consists of:
* a function with some optional accompanying data, or
* an object with a method and some optional accompanying data.
Hooks are registered by adding them to the global $wgHooks array for a given
event. All the following are valid ways to define hooks:
$wgHooks['EventName'][] = 'someFunction'; # function, no data
$wgHooks['EventName'][] = [ 'someFunction', $someData ];
$wgHooks['EventName'][] = [ 'someFunction' ]; # weird, but OK
$wgHooks['EventName'][] = $object; # object only
$wgHooks['EventName'][] = [ $object, 'someMethod' ];
$wgHooks['EventName'][] = [ $object, 'someMethod', $someData ];
$wgHooks['EventName'][] = [ $object ]; # weird but OK
When an event occurs, the function (or object method) will be called with the
optional data provided as well as event-specific parameters. The above examples
would result in the following code being executed when 'EventName' happened:
# function, no data
someFunction( $param1, $param2 )
# function with data
someFunction( $someData, $param1, $param2 )
# object only
$object->onEventName( $param1, $param2 )
# object with method
$object->someMethod( $param1, $param2 )
# object with method and data
$object->someMethod( $someData, $param1, $param2 )
Note that when an object is the hook, and there's no specified method, the
default method called is 'onEventName'. For different events this would be
different: 'onArticleSave', 'onUserLogin', etc.
The extra data is useful if we want to use the same function or object for
different purposes. For example:
$wgHooks['PageContentSaveComplete'][] = [ 'ircNotify', 'TimStarling' ];
$wgHooks['PageContentSaveComplete'][] = [ 'ircNotify', 'brion' ];
This code would result in ircNotify being run twice when an article is saved:
once for 'TimStarling', and once for 'brion'.
Hooks can return three possible values:
* No return value (or null): the hook has operated successfully. Previously,
true was required. This is the default since MediaWiki 1.23.
* "some string": an error occurred; processing should stop and the error
should be shown to the user
* false: the hook has successfully done the work necessary and the calling
function should skip
The last result would be for cases where the hook function replaces the main
functionality. For example, if you wanted to authenticate users to a custom
system (LDAP, another PHP program, whatever), you could do:
$wgHooks['UserLogin'][] = [ 'ldapLogin', $ldapServer ];
function ldapLogin( $username, $password ) {
# log user into LDAP
return false;
}
Returning false makes less sense for events where the action is complete, and
will normally be ignored.
Note that none of the examples made use of create_function() as a way to
attach a function to a hook. This is known to cause problems (notably with
Special:Version), and should be avoided when at all possible.
==Using hooks==
A calling function or method uses the Hooks::run() function to run the hooks
related to a particular event, like so:
class Article {
# ...
function protect() {
$user = $this->getUser();
if ( Hooks::run( 'ArticleProtect', [ $this, $user ] ) ) {
# protect the article
Hooks::run( 'ArticleProtectComplete', [ $this, $user ] );
}
}
}
Hooks::run() returns true if the calling function should continue processing
(the hooks ran OK, or there are no hooks to run), or false if it shouldn't (an
error occurred, or one of the hooks handled the action already). Checking the
return value matters more for "before" hooks than for "complete" hooks.
Note that hook parameters are passed in an array; this is a necessary
inconvenience to make it possible to pass reference values (which can be changed)
by the hook callback.
==Events and parameters==
This is a list of known events and parameters; please add to it if you're going
to add events to the MediaWiki code.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
Parameters which are references for legacy reasons only are annotated with [&].
In new code, handlers for these hooks should be declared with a non-reference
parameter. If the handler is declared with a reference parameter, the reference
should not be modified.
'AbortAutoblock': Return false to cancel an autoblock.
$autoblockip: The IP going to be autoblocked.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$block: The block from which the autoblock is coming.
'AbortDiffCache': Can be used to cancel the caching of a diff.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$diffEngine: DifferenceEngine object
'AbortEmailNotification': Can be used to cancel email notifications for an edit.
$editor: The User who made the change.
$title: The Title of the page that was edited.
$rc: The current RecentChange object.
'AbortTalkPageEmailNotification': Return false to cancel talk page email
notification
$targetUser: the user whom to send talk page email notification
$title: the page title
'ActionBeforeFormDisplay': Before executing the HTMLForm object.
$name: name of the action
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$form: HTMLForm object
$article: Article object
'ActionModifyFormFields': Before creating an HTMLForm object for a page action;
Allows to change the fields on the form that will be generated.
$name: name of the action
&$fields: HTMLForm descriptor array
$article: Article object
'AddNewAccount': DEPRECATED since 1.27! Use LocalUserCreated.
Use AuthManager on special pages Rewrite authentication-related special pages to use AuthManager. All the changes mentioned below only take effect when $wgDisableAuthManager is false. LoginForm is rewritten to use HTMLForm and split into UserLogin and CreateAccount; ChangePassword and PasswordReset are rewritten; ChangeEmail and Preferences are updated. Four new special pages are added to handle the new capabilities of AuthManager (linked accounts, secondary authentication providers): LinkAccounts, UnlinkAccounts, ChangeCredentials, RemoveCredentials. The old form-based hooks (ChangePasswordForm, UserCreateForm, UserLoginForm) are deprecated. A new, more generic hook is available to alter the forms (AuthChangeFormFields); form changes that involve new fields should be done via $wgAuthManagerConfig. UserLoginComplete is limited to web-based login; for more generic functionality UserLoggedIn can be used instead. Hooks that assume password-based login (PrefsPasswordAudit, AbortChangePassword) are removed; the first functionality is replaced by ChangeAuthenticationDataAudit, the second is handled by AuthManager. LoginPasswordResetMessage is removed, the functionality can be recreated via authentication providers. There are several smaller backwards incompatible changes: * Adding fields to the login/signup forms by manipulating the template via the extraInput/extrafields parameters is not supported anymore. Depending on the authn configuration the login/signup process might be multistep and it would be complicated to ensure that extensions can access the data at the right moment. Instead, you can create an AuthenticationProvider which can define its own fields and process them when the authentication is over. (There is B/C support for a transitional period that works with the default login form, but might break with configurations that require multiple steps or redirects.) * Removed cookie redirect check. This was added in 2003 in 9ead07fe9 for the benefit of bots, but with MediaWiki having an API these days there is little reason to keep it. Same for the wpSkipCookieCheck flag (added in 2008 in 29c73e8265). * Instead of embedding a password field on sensitive special pages such as ChangeEmail, such pages rely on AuthManager for elevated security (which typically involves requiring the user to log in again unless their last login was more than a few minutes ago). Accordingly, wgRequirePasswordforEmailChange is removed. * Special:ChangePassword requires login now. * Special:ResetPassword now sends a separate email to each user when called with a shared email address. * the Reason field had a message with 'prefsectiontip' class which was sorta broken but used in extensions for formatting. HTMLForm does not support that, so this commit turns it into a help message which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884 Bug: T110277 Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
2015-09-22 22:50:04 +00:00
After a user account is created.
$user: the User object that was created. (Parameter added in 1.7)
$byEmail: true when account was created "by email" (added in 1.12)
'AfterBuildFeedLinks': Executed in OutputPage.php after all feed links (atom,
rss,...) are created. Can be used to omit specific feeds from being outputted.
You must not use this hook to add feeds, use OutputPage::addFeedLink() instead.
&$feedLinks: Array of created feed links
'AfterFinalPageOutput': Nearly at the end of OutputPage::output() but
before OutputPage::sendCacheControl() and final ob_end_flush() which
will send the buffered output to the client. This allows for last-minute
modification of the output within the buffer by using ob_get_clean().
$output: The OutputPage object where output() was called
'AfterImportPage': When a page import is completed.
2010-07-03 14:33:09 +00:00
$title: Title under which the revisions were imported
$foreignTitle: ForeignTitle object based on data provided by the XML file
2010-07-03 14:33:09 +00:00
$revCount: Number of revisions in the XML file
$sRevCount: Number of successfully imported revisions
2010-07-03 14:33:09 +00:00
$pageInfo: associative array of page information
'AfterParserFetchFileAndTitle': After an image gallery is formed by Parser,
just before adding its HTML to parser output.
$parser: Parser object that called the hook
$ig: Gallery, an object of one of the gallery classes (inheriting from
ImageGalleryBase)
&$html: HTML generated by the gallery
'AlternateEdit': Before checking if a user can edit a page and before showing
the edit form ( EditPage::edit() ). This is triggered on &action=edit.
$editPage: the EditPage object
'AlternateEditPreview': Before generating the preview of the page when editing
( EditPage::getPreviewText() ).
Return false and set $previewHTML and $parserOutput to output custom page
preview HTML.
$editPage: the EditPage object
&$content: the Content object for the text field from the edit page
&$previewHTML: Text to be placed into the page for the preview
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
&$parserOutput: the ParserOutput object for the preview
'AlternateUserMailer': Called before mail is sent so that mail could be logged
(or something else) instead of using PEAR or PHP's mail(). Return false to skip
the regular method of sending mail. Return a string to return a php-mail-error
message containing the error. Returning true will continue with sending email
in the regular way.
$headers: Associative array of headers for the email
$to: MailAddress object or array
$from: From address
$subject: Subject of the email
$body: Body of the message
'AncientPagesQuery': Allow extensions to modify the query used by
Special:AncientPages.
&$tables: tables to join in the query
&$conds: conditions for the query
&$joinConds: join conditions for the query
'APIAfterExecute': After calling the execute() method of an API module. Use
this to extend core API modules.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$module: Module object
'ApiBeforeMain': Before calling ApiMain's execute() method in api.php.
&$main: ApiMain object
'ApiCheckCanExecute': Called during ApiMain::checkCanExecute. Use to further
authenticate and authorize API clients before executing the module. Return
false and set a message to cancel the request.
$module: Module object
$user: Current user
&$message: API message to die with. Specific values accepted depend on the
MediaWiki version:
* 1.29+: IApiMessage, Message, string message key, or key+parameters array to
pass to ApiBase::dieWithError().
* 1.27+: IApiMessage, or a key or key+parameters in ApiBase::$messageMap.
* Earlier: A key or key+parameters in ApiBase::$messageMap.
'ApiDeprecationHelp': Add messages to the 'deprecation-help' warning generated
from ApiBase::addDeprecation().
&$msgs: Message[] Messages to include in the help. Multiple messages will be
joined with spaces.
'ApiFeedContributions::feedItem': Called to convert the result of ContribsPager
into a FeedItem instance that ApiFeedContributions can consume. Implementors of
this hook may cancel the hook to signal that the item is not viewable in the
provided context.
$row: A row of data from ContribsPager. The set of data returned by
ContribsPager can be adjusted by handling the ContribsPager::reallyDoQuery
hook.
$context: An IContextSource implementation.
&$feedItem: Set this to a FeedItem instance if the callback can handle the
provided row. This is provided to the hook as a null, if it is non null then
another callback has already handled the hook.
'ApiFormatHighlight': Use to syntax-highlight API pretty-printed output. When
highlighting, add output to $context->getOutput() and return false.
$context: An IContextSource.
$text: Text to be highlighted.
$mime: MIME type of $text.
$format: API format code for $text.
'APIGetAllowedParams': Use this hook to modify a module's parameters.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$module: ApiBase Module object
&$params: Array of parameters
$flags: int zero or OR-ed flags like ApiBase::GET_VALUES_FOR_HELP
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
'APIGetDescriptionMessages': Use this hook to modify a module's help message.
$module: ApiBase Module object
&$msg: Array of Message objects
'APIGetParamDescriptionMessages': Use this hook to modify a module's parameter
descriptions.
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
$module: ApiBase Module object
&$msg: Array of arrays of Message objects
'APIHelpModifyOutput': Use this hook to modify an API module's help output.
$module: ApiBase Module object
&$help: Array of HTML strings to be joined for the output.
$options: Array Options passed to ApiHelp::getHelp
&$tocData: Array If a TOC is being generated, this array has keys as anchors in
the page and values as for Linker::generateTOC().
API: HTMLize and internationalize the help, add Special:ApiHelp The existing API help, formatted as basically a plain-text document embedded in XML and with a little bolding and a few links syntax-highlighted in after the fact, works ok for experienced programmers but isn't at all newbie-friendly. Further, all the help is hard-coded in English, which isn't very friendly to non-English speakers. So let's rewrite it. The help text is now obtained from i18n messages and output in HTML, with the default display consisting of help for a single module with links to help for other modules. This, of course, necessitates deprecating many of the existing help-related methods and hooks and replacing them with new ones, but backwards compatibility is maintained for almost everything. At the same time, action=paraminfo also needs to support the 'description' and other help-related fields being output in wikitext or HTML, and I11cb063d (to access all modules via the 'modules' parameter instead of having 'modules', 'formatmodules', 'querymodules', and so on) is folded in. And we also add Special:ApiHelp. When directly accessed, it simply redirects to api.php with appropriate parameters. But it's also transcludable to allow up-to-date API help text to be included within the on-wiki documentation. Note this patch doesn't actually add i18n messages for any API modules besides ApiMain and ApiHelp. That will come in a followup patch, but for the moment the backwards-compatibility code handles them nicely. While we're messing with the documentation, we may as well add the "internal" flag requested in bug 62905 (although the 'includeinternal' parameter it also requests doesn't make much sense anymore) and a "deprecated" flag that's needed by several modules now. Bug: 30936 Bug: 38126 Bug: 42343 Bug: 45641 Bug: 62905 Bug: 63211 Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
2014-09-16 17:54:01 +00:00
'ApiMain::moduleManager': Called when ApiMain has finished initializing its
module manager. Can be used to conditionally register API modules.
$moduleManager: ApiModuleManager Module manager instance
'ApiMain::onException': Called by ApiMain::executeActionWithErrorHandling() when
an exception is thrown during API action execution.
$apiMain: Calling ApiMain instance.
$e: Exception object.
'ApiMakeParserOptions': Called from ApiParse and ApiExpandTemplates to allow
extensions to adjust the ParserOptions before parsing.
$options: ParserOptions object
$title: Title to be parsed
$params: Parameter array for the API module
$module: API module (which is also a ContextSource)
&$reset: Set to a ScopedCallback used to reset any hooks after the parse is done.
&$suppressCache: Set true if cache should be suppressed.
'ApiOpenSearchSuggest': Called when constructing the OpenSearch results. Hooks
can alter or append to the array.
&$results: array with integer keys to associative arrays. Keys in associative
array:
- title: Title object.
- redirect from: Title or null.
- extract: Description for this result.
- extract trimmed: If truthy, the extract will not be trimmed to
$wgOpenSearchDescriptionLength.
- image: Thumbnail for this result. Value is an array with subkeys 'source'
(url), 'width', 'height', 'alt', 'align'.
- url: Url for the given title.
'ApiOptions': Called by action=options before applying changes to user
preferences.
$apiModule: Calling ApiOptions object
$user: User object whose preferences are being changed
$changes: Associative array of preference name => value
$resetKinds: Array of strings specifying which options kinds to reset.
See User::resetOptions() and User::getOptionKinds() for possible
values.
'ApiParseMakeOutputPage': Called when preparing the OutputPage object for
ApiParse. This is mainly intended for calling OutputPage::addContentOverride()
or OutputPage::addContentOverrideCallback().
$module: ApiBase (which is also a ContextSource)
$output: OutputPage
'ApiQuery::moduleManager': Called when ApiQuery has finished initializing its
module manager. Can be used to conditionally register API query modules.
$moduleManager: ApiModuleManager Module manager instance
'APIQueryAfterExecute': After calling the execute() method of an
action=query submodule. Use this to extend core API modules.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$module: Module object
'ApiQueryBaseAfterQuery': Called for (some) API query modules after the
database query has returned. An API query module wanting to use this hook
should see the ApiQueryBase::select() and ApiQueryBase::processRow()
documentation.
$module: ApiQueryBase module in question
$result: ResultWrapper|bool returned from the IDatabase::select()
&$hookData: array that was passed to the 'ApiQueryBaseBeforeQuery' hook and
will be passed to the 'ApiQueryBaseProcessRow' hook, intended for inter-hook
communication.
'ApiQueryBaseBeforeQuery': Called for (some) API query modules before a
database query is made. WARNING: It would be very easy to misuse this hook and
break the module! Any joins added *must* join on a unique key of the target
table unless you really know what you're doing. An API query module wanting to
use this hook should see the ApiQueryBase::select() and
ApiQueryBase::processRow() documentation.
$module: ApiQueryBase module in question
&$tables: array of tables to be queried
&$fields: array of columns to select
&$conds: array of WHERE conditionals for query
&$query_options: array of options for the database request
&$join_conds: join conditions for the tables
&$hookData: array that will be passed to the 'ApiQueryBaseAfterQuery' and
'ApiQueryBaseProcessRow' hooks, intended for inter-hook communication.
'ApiQueryBaseProcessRow': Called for (some) API query modules as each row of
the database result is processed. Return false to stop processing the result
set. An API query module wanting to use this hook should see the
ApiQueryBase::select() and ApiQueryBase::processRow() documentation.
$module: ApiQueryBase module in question
$row: stdClass Database result row
&$data: array to be included in the ApiResult.
&$hookData: array that was be passed to the 'ApiQueryBaseBeforeQuery' and
'ApiQueryBaseAfterQuery' hooks, intended for inter-hook communication.
'APIQueryGeneratorAfterExecute': After calling the executeGenerator() method of
an action=query submodule. Use this to extend core API modules.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$module: Module object
[&]$resultPageSet: ApiPageSet object
'APIQueryInfoTokens': DEPRECATED since 1.24! Use ApiQueryTokensRegisterTypes
instead. Use this hook to add custom tokens to prop=info. Every token has an
action, which will be used in the intoken parameter and in the output
(actiontoken="..."), and a callback function which should return the token, or
false if the user isn't allowed to obtain it. The prototype of the callback
function is func($pageid, $title), where $pageid is the page ID of the page the
token is requested for and $title is the associated Title object. In the hook,
just add your callback to the $tokenFunctions array and return true (returning
false makes no sense).
&$tokenFunctions: [ action => callback ]
'APIQueryRecentChangesTokens': DEPRECATED since 1.24! Use
ApiQueryTokensRegisterTypes instead.
Use this hook to add custom tokens to list=recentchanges. Every token has an
action, which will be used in the rctoken parameter and in the output
(actiontoken="..."), and a callback function which should return the token, or
false if the user isn't allowed to obtain it. The prototype of the callback
function is func($pageid, $title, $rc), where $pageid is the page ID of the
page associated to the revision the token is requested for, $title the
associated Title object and $rc the associated RecentChange object. In the
hook, just add your callback to the $tokenFunctions array and return true
(returning false makes no sense).
&$tokenFunctions: [ action => callback ]
'APIQueryRevisionsTokens': DEPRECATED since 1.24! Use
ApiQueryTokensRegisterTypes instead.
Use this hook to add custom tokens to prop=revisions. Every token has an
action, which will be used in the rvtoken parameter and in the output
(actiontoken="..."), and a callback function which should return the token, or
false if the user isn't allowed to obtain it. The prototype of the callback
function is func($pageid, $title, $rev), where $pageid is the page ID of the
page associated to the revision the token is requested for, $title the
associated Title object and $rev the associated Revision object. In the hook,
just add your callback to the $tokenFunctions array and return true (returning
false makes no sense).
&$tokenFunctions: [ action => callback ]
'APIQuerySiteInfoGeneralInfo': Use this hook to add extra information to the
sites general information.
$module: the current ApiQuerySiteinfo module
&$results: array of results, add things here
'APIQuerySiteInfoStatisticsInfo': Use this hook to add extra information to the
sites statistics information.
&$results: array of results, add things here
'ApiQueryTokensRegisterTypes': Use this hook to add additional token types to
action=query&meta=tokens. Note that most modules will probably be able to use
the 'csrf' token instead of creating their own token types.
&$salts: [ type => salt to pass to User::getEditToken(), or array of salt
and key to pass to Session::getToken() ]
'APIQueryUsersTokens': DEPRECATED since 1.24! Use ApiQueryTokensRegisterTypes
instead.
Use this hook to add custom token to list=users. Every token has an action,
which will be used in the ustoken parameter and in the output
(actiontoken="..."), and a callback function which should return the token, or
false if the user isn't allowed to obtain it. The prototype of the callback
function is func($user) where $user is the User object. In the hook, just add
your callback to the $tokenFunctions array and return true (returning false
makes no sense).
&$tokenFunctions: [ action => callback ]
'ApiQueryWatchlistExtractOutputData': Extract row data for ApiQueryWatchlist.
$module: ApiQueryWatchlist instance
$watchedItem: WatchedItem instance
$recentChangeInfo: Array of recent change info data
&$vals: Associative array of data to be output for the row
'ApiQueryWatchlistPrepareWatchedItemQueryServiceOptions': Populate the options
to be passed from ApiQueryWatchlist to WatchedItemQueryService.
$module: ApiQueryWatchlist instance
$params: Array of parameters, as would be returned by $module->extractRequestParams()
&$options: Array of options for WatchedItemQueryService::getWatchedItemsWithRecentChangeInfo()
'ApiRsdServiceApis': Add or remove APIs from the RSD services list. Each service
should have its own entry in the $apis array and have a unique name, passed as
key for the array that represents the service data. In this data array, the
key-value-pair identified by the apiLink key is required.
&$apis: array of services
'ApiTokensGetTokenTypes': DEPRECATED since 1.24! Use ApiQueryTokensRegisterTypes instead.
Use this hook to extend action=tokens with new token types.
&$tokenTypes: supported token types in format 'type' => callback function
used to retrieve this type of tokens.
'ApiValidatePassword': Called from ApiValidatePassword.
$module: ApiValidatePassword instance.
&$r: Result array.
'Article::MissingArticleConditions': Before fetching deletion & move log entries
to display a message of a non-existing page being deleted/moved, give extensions
a chance to hide their (unrelated) log entries.
&$conds: Array of query conditions (all of which have to be met; conditions will
AND in the final query)
$logTypes: Array of log types being queried
'ArticleConfirmDelete': Before writing the confirmation form for article
deletion.
$article: the article (object) being deleted
$output: the OutputPage object
&$reason: the reason (string) the article is being deleted
'ArticleContentOnDiff': Before showing the article content below a diff. Use
this to change the content in this area or how it is loaded.
$diffEngine: the DifferenceEngine
$output: the OutputPage object
2010-10-26 22:34:18 +00:00
'ArticleRevisionViewCustom': Allows custom rendering of an article's content.
Note that it is preferable to implement proper handing for a custom data type using
the ContentHandler facility.
$revision: content of the page, as a RevisionRecord object, or null if the revision
could not be loaded. May also be a fake that wraps content supplied by an extension.
$title: title of the page
$oldid: the requested revision id, or 0 for the currrent revision.
$output: a ParserOutput object
'ArticleDelete': Before an article is deleted.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: the WikiPage (object) being deleted
[&]$user: the user (object) deleting the article
&$reason: the reason (string) the article is being deleted
&$error: if the deletion was prohibited, the (raw HTML) error message to display
(added in 1.13)
&$status: Status object, modify this to throw an error. Overridden by $error
(added in 1.20)
$suppress: Whether this is a suppression deletion or not (added in 1.27)
'ArticleDeleteAfterSuccess': Output after an article has been deleted.
$title: Title of the article that has been deleted.
$outputPage: OutputPage that can be used to append the output.
'ArticleDeleteComplete': After an article is deleted.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: the WikiPage that was deleted
[&]$user: the user that deleted the article
$reason: the reason the article was deleted
$id: id of the article that was deleted
$content: the Content of the deleted page (or null, when deleting a broken page)
$logEntry: the ManualLogEntry used to record the deletion
$archivedRevisionCount: the number of revisions archived during the deletion
'ArticleEditUpdateNewTalk': Before updating user_newtalk when a user talk page
was changed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: WikiPage (object) of the user talk page
$recipient: User (object) who's talk page was edited
'ArticleEditUpdates': DEPRECATED since 1.35, use RevisionDataUpdates instead.
When edit updates (mainly link tracking) are made when an article has been changed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: the WikiPage (object)
[&]$editInfo: data holder that includes the parser output ($editInfo->output) for
that page after the change
$changed: bool for if the page was changed
'ArticleEditUpdatesDeleteFromRecentchanges': DEPRECATED since 1.35, use RecentChange_save
or similar instead. Before deleting old entries from
recentchanges table, return false to not delete old entries.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: WikiPage (object) being modified
'ArticleFromTitle': when creating an article object from a title object using
Wiki::articleFromTitle().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title (object) used to create the article object
&$article: Article (object) that will be returned
$context: IContextSource (object)
'ArticleMergeComplete': After merging to article using Special:Mergehistory.
$targetTitle: target title (object)
$destTitle: destination title (object)
'ArticlePageDataAfter': After loading data of an article from the database.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: WikiPage (object) whose data were loaded
&$row: row (object) returned from the database server
'ArticlePageDataBefore': Before loading data of an article from the database.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: WikiPage (object) that data will be loaded
&$fields: fields (array) to load from the database
&$tables: tables (array) to load from the database
&$joinConds: join conditions (array) to load from the database
'ArticlePrepareTextForEdit': Called when preparing text to be saved.
$wikiPage: the WikiPage being saved
$popts: parser options to be used for pre-save transformation
'ArticleProtect': Before an article is protected.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: the WikiPage being protected
[&]$user: the user doing the protection
$protect: Set of restriction keys
$reason: Reason for protect
'ArticleProtectComplete': After an article is protected.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: the WikiPage that was protected
[&]$user: the user who did the protection
$protect: Set of restriction keys
$reason: Reason for protect
'ArticlePurge': Before executing "&action=purge".
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: WikiPage (object) to purge
'ArticleRevisionUndeleted': DEPRECATED since 1.35! Use RevisionUndeleted instead.
After an article revision is restored.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: the article title
$revision: the revision
$oldPageID: the page ID of the revision when archived (may be null)
'ArticleRevisionVisibilitySet': Called when changing visibility of one or more
revisions of an article.
$title: Title object of the article
$ids: Ids to set the visibility for
$visibilityChangeMap: Map of revision id to oldBits and newBits. This array can be
examined to determine exactly what visibility bits have changed for each
revision. This array is of the form
[id => ['oldBits' => $oldBits, 'newBits' => $newBits], ... ]
'ArticleRollbackComplete': DEPRECATED since 1.35! Use RollbackComplete instead.
After an article rollback is completed.
$wikiPage: the WikiPage that was edited
$user: the user who did the rollback
$revision: the revision the page was reverted back to
$current: the reverted revision
'ArticleShowPatrolFooter': Called at the beginning of Article#showPatrolFooter.
Extensions can use this to not show the [mark as patrolled] link in certain
circumstances.
$article: the Article object
'ArticleUndelete': When one or more revisions of an article are restored.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title corresponding to the article restored
$create: Whether or not the restoration caused the page to be created (i.e. it
didn't exist before).
$comment: The comment associated with the undeletion.
$oldPageId: ID of page previously deleted (from archive table). This ID will be used
for the restored page.
$restoredPages: Set of page IDs that have revisions restored for this undelete,
with keys being page IDs and values are 'true'.
'ArticleUndeleteLogEntry': When a log entry is generated but not yet saved.
$pageArchive: the PageArchive object
&$logEntry: ManualLogEntry object
$user: User who is performing the log action
'ArticleUpdateBeforeRedirect': After a page is updated (usually on save), before
the user is redirected back to the page.
$article: the article
&$sectionanchor: The section anchor link (e.g. "#overview" )
&$extraq: Extra query parameters which can be added via hooked functions
'ArticleViewFooter': After showing the footer section of an ordinary page view
$article: Article object
$patrolFooterShown: boolean whether patrol footer is shown
'ArticleViewHeader': Control article output. Called before the parser cache is about
to be tried for article viewing.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$article: the article
2007-06-03 22:34:53 +00:00
&$pcache: whether to try the parser cache or not
&$outputDone: whether the output for this page finished or not. Set to
a ParserOutput object to both indicate that the output is done and what
parser output was used.
2007-06-03 22:34:53 +00:00
'ArticleViewRedirect': Before setting "Redirected from ..." subtitle when a
redirect was followed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$article: target article (object)
Use AuthManager on special pages Rewrite authentication-related special pages to use AuthManager. All the changes mentioned below only take effect when $wgDisableAuthManager is false. LoginForm is rewritten to use HTMLForm and split into UserLogin and CreateAccount; ChangePassword and PasswordReset are rewritten; ChangeEmail and Preferences are updated. Four new special pages are added to handle the new capabilities of AuthManager (linked accounts, secondary authentication providers): LinkAccounts, UnlinkAccounts, ChangeCredentials, RemoveCredentials. The old form-based hooks (ChangePasswordForm, UserCreateForm, UserLoginForm) are deprecated. A new, more generic hook is available to alter the forms (AuthChangeFormFields); form changes that involve new fields should be done via $wgAuthManagerConfig. UserLoginComplete is limited to web-based login; for more generic functionality UserLoggedIn can be used instead. Hooks that assume password-based login (PrefsPasswordAudit, AbortChangePassword) are removed; the first functionality is replaced by ChangeAuthenticationDataAudit, the second is handled by AuthManager. LoginPasswordResetMessage is removed, the functionality can be recreated via authentication providers. There are several smaller backwards incompatible changes: * Adding fields to the login/signup forms by manipulating the template via the extraInput/extrafields parameters is not supported anymore. Depending on the authn configuration the login/signup process might be multistep and it would be complicated to ensure that extensions can access the data at the right moment. Instead, you can create an AuthenticationProvider which can define its own fields and process them when the authentication is over. (There is B/C support for a transitional period that works with the default login form, but might break with configurations that require multiple steps or redirects.) * Removed cookie redirect check. This was added in 2003 in 9ead07fe9 for the benefit of bots, but with MediaWiki having an API these days there is little reason to keep it. Same for the wpSkipCookieCheck flag (added in 2008 in 29c73e8265). * Instead of embedding a password field on sensitive special pages such as ChangeEmail, such pages rely on AuthManager for elevated security (which typically involves requiring the user to log in again unless their last login was more than a few minutes ago). Accordingly, wgRequirePasswordforEmailChange is removed. * Special:ChangePassword requires login now. * Special:ResetPassword now sends a separate email to each user when called with a shared email address. * the Reason field had a message with 'prefsectiontip' class which was sorta broken but used in extensions for formatting. HTMLForm does not support that, so this commit turns it into a help message which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884 Bug: T110277 Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
2015-09-22 22:50:04 +00:00
'AuthChangeFormFields': After converting a field information array obtained
from a set of AuthenticationRequest classes into a form descriptor; hooks
can tweak the array to change how login etc. forms should look.
$requests: array of AuthenticationRequests the fields are created from
$fieldInfo: field information array (union of all
AuthenticationRequest::getFieldInfo() responses).
Use AuthManager on special pages Rewrite authentication-related special pages to use AuthManager. All the changes mentioned below only take effect when $wgDisableAuthManager is false. LoginForm is rewritten to use HTMLForm and split into UserLogin and CreateAccount; ChangePassword and PasswordReset are rewritten; ChangeEmail and Preferences are updated. Four new special pages are added to handle the new capabilities of AuthManager (linked accounts, secondary authentication providers): LinkAccounts, UnlinkAccounts, ChangeCredentials, RemoveCredentials. The old form-based hooks (ChangePasswordForm, UserCreateForm, UserLoginForm) are deprecated. A new, more generic hook is available to alter the forms (AuthChangeFormFields); form changes that involve new fields should be done via $wgAuthManagerConfig. UserLoginComplete is limited to web-based login; for more generic functionality UserLoggedIn can be used instead. Hooks that assume password-based login (PrefsPasswordAudit, AbortChangePassword) are removed; the first functionality is replaced by ChangeAuthenticationDataAudit, the second is handled by AuthManager. LoginPasswordResetMessage is removed, the functionality can be recreated via authentication providers. There are several smaller backwards incompatible changes: * Adding fields to the login/signup forms by manipulating the template via the extraInput/extrafields parameters is not supported anymore. Depending on the authn configuration the login/signup process might be multistep and it would be complicated to ensure that extensions can access the data at the right moment. Instead, you can create an AuthenticationProvider which can define its own fields and process them when the authentication is over. (There is B/C support for a transitional period that works with the default login form, but might break with configurations that require multiple steps or redirects.) * Removed cookie redirect check. This was added in 2003 in 9ead07fe9 for the benefit of bots, but with MediaWiki having an API these days there is little reason to keep it. Same for the wpSkipCookieCheck flag (added in 2008 in 29c73e8265). * Instead of embedding a password field on sensitive special pages such as ChangeEmail, such pages rely on AuthManager for elevated security (which typically involves requiring the user to log in again unless their last login was more than a few minutes ago). Accordingly, wgRequirePasswordforEmailChange is removed. * Special:ChangePassword requires login now. * Special:ResetPassword now sends a separate email to each user when called with a shared email address. * the Reason field had a message with 'prefsectiontip' class which was sorta broken but used in extensions for formatting. HTMLForm does not support that, so this commit turns it into a help message which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884 Bug: T110277 Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
2015-09-22 22:50:04 +00:00
&$formDescriptor: HTMLForm descriptor. The special key 'weight' can be set
to change the order of the fields.
$action: one of the AuthManager::ACTION_* constants.
'AuthManagerLoginAuthenticateAudit': A login attempt either succeeded or failed
for a reason other than misconfiguration or session loss. No return data is
accepted; this hook is for auditing only.
$response: The MediaWiki\Auth\AuthenticationResponse in either a PASS or FAIL
state.
$user: The User object being authenticated against, or null if authentication
failed before getting that far.
$username: A guess at the user name being authenticated, or null if we can't
even determine that. When $user is not null, it can be in the form of
<username>@<more info> (e.g. for bot passwords).
$extraData: An array (string => string) with extra information, intended to be
added to log contexts. Fields it might include:
- appId: the application ID, only if the login was with a bot password
'AutopromoteCondition': Check autopromote condition for user.
$type: condition type
$args: arguments
$user: user
&$result: result of checking autopromote condition
'BacklinkCacheGetConditions': Allows to set conditions for query when links to
certain title are fetched.
$table: table name
$title: title of the page to which backlinks are sought
&$conds: query conditions
'BacklinkCacheGetPrefix': Allows to set prefix for a specific link table.
$table: table name
&$prefix: prefix
'BadImage': When checking against the bad image list. Change $bad and return
false to override. If an image is "bad", it is not rendered inline in wiki
pages or galleries in category pages.
$name: Image name being checked
&$bad: Whether or not the image is "bad"
'BaseTemplateAfterPortlet': After output of portlets, allow injecting
custom HTML after the section. Any uses of the hook need to handle escaping.
$template: BaseTemplate
$portlet: string portlet name
&$html: string
'BaseTemplateToolbox': Called by BaseTemplate when building the $toolbox array
and returning it for the skin to output. You can add items to the toolbox while
still letting the skin make final decisions on skin-specific markup conventions
using this hook.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sk: The BaseTemplate base skin template
&$toolbox: An array of toolbox items, see BaseTemplate::getToolbox and
BaseTemplate::makeListItem for details on the format of individual items
inside of this array.
'BeforeDisplayNoArticleText': Before displaying message key "noarticletext" or
"noarticletext-nopermission" at Article::showMissingArticle().
$article: article object
'BeforeHttpsRedirect': Prior to forcing HTTP->HTTPS redirect. Gives a chance to
override how the redirect is output by modifying, or by returning false, and
letting standard HTTP rendering take place.
ATTENTION: This hook is likely to be removed soon due to overall design of the
system.
$context: IContextSource object
&$redirect: string URL, modifiable
'BeforeInitialize': Before anything is initialized in
MediaWiki::performRequest().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title being used for request
[&]$unused: null
[&]$output: OutputPage object
[&]$user: User
$request: WebRequest object
$mediaWiki: Mediawiki object
'BeforePageDisplay': Prior to outputting a page.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$out: OutputPage object
[&]$skin: Skin object
2007-08-28 21:53:50 +00:00
'BeforePageRedirect': Prior to sending an HTTP redirect. Gives a chance to
override how the redirect is output by modifying, or by returning false and
taking over the output.
$out: OutputPage object
&$redirect: URL, modifiable
&$code: HTTP code (eg '301' or '302'), modifiable
'BeforeParserFetchFileAndTitle': Before an image is rendered by Parser.
$parser: Parser object
$nt: the image title
&$options: array of options to RepoGroup::findFile. If it contains 'broken'
as a key then the file will appear as a broken thumbnail.
&$descQuery: query string to add to thumbnail URL
'BeforeParserFetchTemplateAndtitle': Before a template is fetched by Parser.
$parser: Parser object
$title: title of the template
2007-06-01 13:17:24 +00:00
&$skip: skip this template and link it?
&$id: the id of the revision being parsed
'BeforeParserrenderImageGallery': DEPRECATED since 1.35!
Before an image gallery is rendered by Parser.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
[&]$ig: ImageGallery object
2007-06-01 13:17:24 +00:00
'BeforeResetNotificationTimestamp': Before the notification timestamp of a
watched item is reset.
&$userObj: User object
&$titleObj: Title object
$force: If this is the string "force", then the reset will be done even if the
page is not watched.
&$oldid: The revision ID
'BeforeWelcomeCreation': Before the welcomecreation message is displayed to a
newly created user.
&$welcome_creation_msg: MediaWiki message name to display on the welcome screen
to a newly created user account.
&$injected_html: Any HTML to inject after the "logged in" message of a newly
created user account
'BitmapHandlerCheckImageArea': By BitmapHandler::normaliseParams, after all
normalizations have been performed, except for the $wgMaxImageArea check.
$image: File
&$params: Array of parameters
&$checkImageAreaHookResult: null, set to true or false to override the
$wgMaxImageArea check result.
'BitmapHandlerTransform': before a file is transformed, gives extension the
possibility to transform it themselves
$handler: BitmapHandler
$image: File
&$scalerParams: Array with scaler parameters
&$mto: null, set to a MediaTransformOutput
'BlockIp': Before an IP address or user is blocked.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$block: the Block object about to be saved
[&]$user: the user _doing_ the block (not the one being blocked)
&$reason: if the hook is aborted, the error message to be returned in an array
'BlockIpComplete': After an IP address or user is blocked.
$block: the Block object that was saved
$user: the user who did the block (not the one being blocked)
$priorBlock: the Block object for the prior block or null if there was none
'BookInformation': Before information output on Special:Booksources.
$isbn: ISBN to show information for
$output: OutputPage object in use
'CanIPUseHTTPS': Determine whether the client at a given source IP is likely
to be able to access the wiki via HTTPS.
$ip: The IP address in human-readable form
&$canDo: This reference should be set to false if the client may not be able
to use HTTPS
'CanonicalNamespaces': For extensions adding their own namespaces or altering
the defaults.
Note that if you need to specify namespace protection or content model for
a namespace that is added in a CanonicalNamespaces hook handler, you
should do so by altering $wgNamespaceProtection and
$wgNamespaceContentModels outside the handler, in top-level scope. The
point at which the CanonicalNamespaces hook fires is too late for altering
these variables. This applies even if the namespace addition is
conditional; it is permissible to declare a content model and protection
for a namespace and then decline to actually register it.
2010-08-24 20:12:15 +00:00
&$namespaces: Array of namespace numbers with corresponding canonical names
'CategoryAfterPageAdded': After a page is added to a category.
$category: Category that page was added to
$wikiPage: WikiPage that was added
'CategoryAfterPageRemoved': After a page is removed from a category.
$category: Category that page was removed from
$wikiPage: WikiPage that was removed
$id: the page ID (original ID in case of page deletions)
'CategoryPageView': Before viewing a categorypage in CategoryPage::view.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$catpage: CategoryPage instance
2007-08-28 21:53:50 +00:00
'CategoryViewer::doCategoryQuery': After querying for pages to be displayed
in a Category page. Gives extensions the opportunity to batch load any
related data about the pages.
$type: The category type. Either 'page', 'file' or 'subcat'
$res: Query result from Wikimedia\Rdbms\IDatabase::select()
'CategoryViewer::generateLink': Before generating an output link allow
extensions opportunity to generate a more specific or relevant link.
$type: The category type. Either 'page', 'img' or 'subcat'
$title: Title object for the categorized page
$html: Requested html content of anchor
&$link: Returned value. When set to a non-null value by a hook subscriber
this value will be used as the anchor instead of Linker::link
Use AuthManager on special pages Rewrite authentication-related special pages to use AuthManager. All the changes mentioned below only take effect when $wgDisableAuthManager is false. LoginForm is rewritten to use HTMLForm and split into UserLogin and CreateAccount; ChangePassword and PasswordReset are rewritten; ChangeEmail and Preferences are updated. Four new special pages are added to handle the new capabilities of AuthManager (linked accounts, secondary authentication providers): LinkAccounts, UnlinkAccounts, ChangeCredentials, RemoveCredentials. The old form-based hooks (ChangePasswordForm, UserCreateForm, UserLoginForm) are deprecated. A new, more generic hook is available to alter the forms (AuthChangeFormFields); form changes that involve new fields should be done via $wgAuthManagerConfig. UserLoginComplete is limited to web-based login; for more generic functionality UserLoggedIn can be used instead. Hooks that assume password-based login (PrefsPasswordAudit, AbortChangePassword) are removed; the first functionality is replaced by ChangeAuthenticationDataAudit, the second is handled by AuthManager. LoginPasswordResetMessage is removed, the functionality can be recreated via authentication providers. There are several smaller backwards incompatible changes: * Adding fields to the login/signup forms by manipulating the template via the extraInput/extrafields parameters is not supported anymore. Depending on the authn configuration the login/signup process might be multistep and it would be complicated to ensure that extensions can access the data at the right moment. Instead, you can create an AuthenticationProvider which can define its own fields and process them when the authentication is over. (There is B/C support for a transitional period that works with the default login form, but might break with configurations that require multiple steps or redirects.) * Removed cookie redirect check. This was added in 2003 in 9ead07fe9 for the benefit of bots, but with MediaWiki having an API these days there is little reason to keep it. Same for the wpSkipCookieCheck flag (added in 2008 in 29c73e8265). * Instead of embedding a password field on sensitive special pages such as ChangeEmail, such pages rely on AuthManager for elevated security (which typically involves requiring the user to log in again unless their last login was more than a few minutes ago). Accordingly, wgRequirePasswordforEmailChange is removed. * Special:ChangePassword requires login now. * Special:ResetPassword now sends a separate email to each user when called with a shared email address. * the Reason field had a message with 'prefsectiontip' class which was sorta broken but used in extensions for formatting. HTMLForm does not support that, so this commit turns it into a help message which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884 Bug: T110277 Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
2015-09-22 22:50:04 +00:00
'ChangeAuthenticationDataAudit': Called when user changes his password.
No return data is accepted; this hook is for auditing only.
$req: AuthenticationRequest object describing the change (and target user)
$status: StatusValue with the result of the action
'ChangesListInitRows': Batch process change list rows prior to rendering.
$changesList: ChangesList instance
$rows: The data that will be rendered. May be a \Wikimedia\Rdbms\IResultWrapper
instance or an array.
'ChangesListInsertArticleLink': Override or augment link to article in RC list.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$changesList: ChangesList instance.
&$articlelink: HTML of link to article (already filled-in).
&$s: HTML of row that is being constructed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$rc: RecentChange instance.
$unpatrolled: Whether or not we are showing unpatrolled changes.
$watched: Whether or not the change is watched by the user.
'ChangesListSpecialPageQuery': Called when building SQL query on pages
inheriting from ChangesListSpecialPage (in core: RecentChanges,
RecentChangesLinked and Watchlist).
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
Do not use this to implement individual filters if they are compatible with the
ChangesListFilter and ChangesListFilterGroup structure.
Instead, use sub-classes of those classes, in conjunction with the
ChangesListSpecialPageStructuredFilters hook.
This hook can be used to implement filters that do not implement that structure,
or custom behavior that is not an individual filter.
$name: name of the special page, e.g. 'Watchlist'
&$tables: array of tables to be queried
&$fields: array of columns to select
&$conds: array of WHERE conditionals for query
&$query_options: array of options for the database request
&$join_conds: join conditions for the tables
$opts: FormOptions for this request
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
'ChangesListSpecialPageStructuredFilters': Called to allow extensions to register
filters for pages inheriting from ChangesListSpecialPage (in core: RecentChanges,
RecentChangesLinked, and Watchlist). Generally, you will want to construct
new ChangesListBooleanFilter or ChangesListStringOptionsFilter objects.
When constructing them, you specify which group they belong to. You can reuse
existing groups (accessed through $special->getFilterGroup), or create your own
(ChangesListBooleanFilterGroup or ChangesListStringOptionsFilterGroup).
If you create new groups, you must register them with $special->registerFilterGroup.
Note that this is called regardless of whether the user is currently using
the new (structured) or old (unstructured) filter UI. If you want your boolean
filter to show on both the new and old UI, specify all the supported fields.
These include showHide, label, and description.
See the constructor of each ChangesList* class for documentation of supported
fields.
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$special: ChangesListSpecialPage instance
'ChangeTagAfterDelete': Called after a change tag has been deleted (that is,
removed from all revisions and log entries to which it was applied). This gives
extensions a chance to take it off their books.
$tag: name of the tag
&$status: Status object. Add warnings to this as required. There is no point
setting errors, as the deletion has already been partly carried out by this
point.
'ChangeTagCanCreate': Tell whether a change tag should be able to be created
from the UI (Special:Tags) or via the API. You could use this hook if you want
to reserve a specific "namespace" of tags, or something similar.
$tag: name of the tag
$user: user initiating the action
&$status: Status object. Add your errors using `$status->fatal()` or warnings
using `$status->warning()`. Errors and warnings will be relayed to the user.
If you set an error, the user will be unable to create the tag.
'ChangeTagCanDelete': Tell whether a change tag should be able to be
deleted from the UI (Special:Tags) or via the API. The default is that tags
defined using the ListDefinedTags hook are not allowed to be deleted unless
specifically allowed. If you wish to allow deletion of the tag, set
`$status = Status::newGood()` to allow deletion, and then `return false` from
the hook function. Ensure you consume the 'ChangeTagAfterDelete' hook to carry
out custom deletion actions.
$tag: name of the tag
$user: user initiating the action
&$status: Status object. See above.
'ChangeTagsListActive': Allows you to nominate which of the tags your extension
uses are in active use.
&$tags: list of all active tags. Append to this array.
'ChangeTagsAfterUpdateTags': Called after tags have been updated with the
ChangeTags::updateTags function. Params:
$addedTags: tags effectively added in the update
$removedTags: tags effectively removed in the update
$prevTags: tags that were present prior to the update
$rc_id: recentchanges table id
$rev_id: revision table id
$log_id: logging table id
$params: tag params
$rc: RecentChange being tagged when the tagging accompanies the action, or null
$user: User who performed the tagging when the tagging is subsequent to the
action, or null
'ChangeTagsAllowedAdd': Called when checking if a user can add tags to a change.
&$allowedTags: List of all the tags the user is allowed to add. Any tags the
user wants to add ($addTags) that are not in this array will cause it to fail.
You may add or remove tags to this array as required.
$addTags: List of tags user intends to add.
$user: User who is adding the tags.
'ChangeUserGroups': Called before user groups are changed.
$performer: The User who will perform the change
$user: The User whose groups will be changed
&$add: The groups that will be added
&$remove: The groups that will be removed
'Collation::factory': Called if $wgCategoryCollation is an unknown collation.
$collationName: Name of the collation in question
&$collationObject: Null. Replace with a subclass of the Collation class that
implements the collation given in $collationName.
'ConfirmEmailComplete': Called after a user's email has been confirmed
successfully.
$user: user (object) whose email is being confirmed
'ContentAlterParserOutput': Modify parser output for a given content object.
Called by Content::getParserOutput after parsing has finished. Can be used
for changes that depend on the result of the parsing but have to be done
before LinksUpdate is called (such as adding tracking categories based on
the rendered HTML).
$content: The Content to render
$title: Title of the page, as context
$parserOutput: ParserOutput to manipulate
'ContentGetParserOutput': Customize parser output for a given content object,
called by AbstractContent::getParserOutput. May be used to override the normal
model-specific rendering of page content.
$content: The Content to render
$title: Title of the page, as context
$revId: The revision ID, as context
$options: ParserOptions for rendering. To avoid confusing the parser cache,
the output can only depend on parameters provided to this hook function, not
on global state.
$generateHtml: boolean, indicating whether full HTML should be generated. If
false, generation of HTML may be skipped, but other information should still
be present in the ParserOutput object.
&$output: ParserOutput, to manipulate or replace
'ContentHandlerDefaultModelFor': Called when the default content model is
determined for a given title. May be used to assign a different model for that
title.
$title: the Title in question
&$model: the model name. Use with CONTENT_MODEL_XXX constants.
Introduce ContentAlterParserOutput hook This hook is the counterpart of ContentGetParserOutput: it gives high-level access to the parsing of a content object (as opposed to lower-level parser hooks like ParserBefore*/ParserAfter* which are called for all kinds of non-content input like interface messages and don't have the necessary context to know what kind of input is being parsed), but it is called when the parsing has already finished. The intention is to provide a convenient location for ParserOutput modifications which depend on some global property of the parsed content, but need to happen before LinksUpdate. Currently there are no hooks between parsing (initiated by WikiPage::doEditUpdates() calling WikiPage::prepareContentForEdit()) and updating the link tables (initiated by the same method calling Content::getSecondaryDataUpdates()), so any hook an extension would try to use would face one of the following problems: * the parsing output is not available yet * LinksUpdate has run already, modifying list properties is unsafe * there is not enough context to tell what's being parsed A typical use of this hook would be to add tracking categories when something is missing from the text (e.g. there are no references). For the concrete use case, see I43ed79b6a54cd31820ecae8139e29c5880f5dd1b Alternative approaches that have been suggested and do not require a new hook but are not robust / do not rely on a clear contract: * use ParserAfterTidy or a similar hook, assume that the input being parsed is the main page content iff limit reporting is enabled * use ParserAfterTidy or a similar hook, assume that the input being parsed is the main page content iff ParserOptions::getInterfaceMessage() is false (this would yield some false positives, but in those cases adding a tracking category would probably have no effect) Change-Id: I685b285fcc772382993116f7822a832eeecc0681
2014-09-19 10:09:54 +00:00
'ContentHandlerForModelID': Called when a ContentHandler is requested for
a given content model name, but no entry for that model exists in
$wgContentHandlers.
Note: if your extension implements additional models via this hook, please
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
use GetContentModels hook to make them known to core.
$modeName: the requested content model name
&$handler: set this to a ContentHandler object, if desired.
'ContentModelCanBeUsedOn': Called to determine whether that content model can
be used on a given page. This is especially useful to prevent some content
models to be used in some special location.
$contentModel: ID of the content model in question
$title: the Title in question.
&$ok: Output parameter, whether it is OK to use $contentModel on $title.
Handler functions that modify $ok should generally return false to prevent
further hooks from further modifying $ok.
'ContribsPager::getQueryInfo': Before the contributions query is about to run
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$pager: Pager object for contributions
2011-08-19 20:58:32 +00:00
&$queryInfo: The query for the contribs Pager
'ContribsPager::reallyDoQuery': Called before really executing the query for My
Contributions
&$data: an array of results of all contribs queries
$pager: The ContribsPager object hooked into
$offset: Index offset, inclusive
$limit: Exact query limit
$descending: Query direction, false for ascending, true for descending
'ContributionsLineEnding': Called before a contributions HTML line is finished
$page: SpecialPage object for contributions
&$ret: the HTML line
$row: the DB row for this line
&$classes: the classes to add to the surrounding <li>
&$attribs: associative array of other HTML attributes for the <li> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'ContributionsToolLinks': Change tool links above Special:Contributions
$id: User identifier
$title: User page title
&$tools: Array of tool links
$specialPage: SpecialPage instance for context and services. Can be either
SpecialContributions or DeletedContributionsPage. Extensions should type
hint against a generic SpecialPage though.
'ConvertContent': Called by AbstractContent::convert when a conversion to
another content model is requested.
Handler functions that modify $result should generally return false to disable
further attempts at conversion.
$content: The Content object to be converted.
$toModel: The ID of the content model to convert to.
$lossy: boolean indicating whether lossy conversion is allowed.
&$result: Output parameter, in case the handler function wants to provide a
converted Content object. Note that $result->getContentModel() must return
$toModel.
'ContentSecurityPolicyDefaultSource': Modify the allowed CSP load sources. This
affects all directives except for the script directive. If you want to add a
script source, see ContentSecurityPolicyScriptSource hook.
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
&$defaultSrc: Array of Content-Security-Policy allowed sources
$policyConfig: Current configuration for the Content-Security-Policy header
$mode: ContentSecurityPolicy::REPORT_ONLY_MODE or
ContentSecurityPolicy::FULL_MODE depending on type of header
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
'ContentSecurityPolicyDirectives': Modify the content security policy
directives. Use this only if ContentSecurityPolicyDefaultSource and
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
ContentSecurityPolicyScriptSource do not meet your needs.
&$directives: Array of CSP directives
$policyConfig: Current configuration for the CSP header
$mode: ContentSecurityPolicy::REPORT_ONLY_MODE or
ContentSecurityPolicy::FULL_MODE depending on type of header
'ContentSecurityPolicyScriptSource': Modify the allowed CSP script sources.
Note that you also have to use ContentSecurityPolicyDefaultSource if you
want non-script sources to be loaded from
whatever you add.
&$scriptSrc: Array of CSP directives
$policyConfig: Current configuration for the CSP header
$mode: ContentSecurityPolicy::REPORT_ONLY_MODE or
ContentSecurityPolicy::FULL_MODE depending on type of header
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
'CustomEditor': When invoking the page editor
Return true to allow the normal editor to be used, or false if implementing
a custom editor, e.g. for a special namespace, etc.
$article: Article being edited
$user: User performing the edit
'DeletedContribsPager::reallyDoQuery': Called before really executing the query
for Special:DeletedContributions
Similar to ContribsPager::reallyDoQuery
&$data: an array of results of all contribs queries
$pager: The DeletedContribsPager object hooked into
$offset: Index offset, inclusive
$limit: Exact query limit
$descending: Query direction, false for ascending, true for descending
'DeletedContributionsLineEnding': Called before a DeletedContributions HTML line
is finished.
Similar to ContributionsLineEnding
$page: SpecialPage object for DeletedContributions
&$ret: the HTML line
$row: the DB row for this line
&$classes: the classes to add to the surrounding <li>
&$attribs: associative array of other HTML attributes for the <li> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'DeleteUnknownPreferences': Called by the cleanupPreferences.php maintenance
script to build a WHERE clause with which to delete preferences that are not
known about. This hook is used by extensions that have dynamically-named
preferences that should not be deleted in the usual cleanup process. For
example, the Gadgets extension creates preferences prefixed with 'gadget-', and
so anything with that prefix is excluded from the deletion.
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
&$where: An array that will be passed as the $cond parameter to
IDatabase::select() to determine what will be deleted from the user_properties
table.
$db: The IDatabase object, useful for accessing $db->buildLike() etc.
'DifferenceEngineAfterLoadNewText': called in DifferenceEngine::loadNewText()
after the new revision's content has been loaded into the class member variable
$differenceEngine->mNewContent but before returning true from this function.
$differenceEngine: DifferenceEngine object
'DifferenceEngineLoadTextAfterNewContentIsLoaded': called in
DifferenceEngine::loadText() after the new revision's content has been loaded
into the class member variable $differenceEngine->mNewContent but before
checking if the variable's value is null.
This hook can be used to inject content into said class member variable.
$differenceEngine: DifferenceEngine object
'DifferenceEngineMarkPatrolledLink': Allows extensions to change the "mark as
patrolled" link which is shown both on the diff header as well as on the bottom
of a page, usually wrapped in a span element which has class="patrollink".
$differenceEngine: DifferenceEngine object
&$markAsPatrolledLink: The "mark as patrolled" link HTML (string)
$rcid: Recent change ID (rc_id) for this change (int)
'DifferenceEngineMarkPatrolledRCID': Allows extensions to possibly change the
rcid parameter. For example the rcid might be set to zero due to the user being
the same as the performer of the change but an extension might still want to
show it under certain conditions.
&$rcid: rc_id (int) of the change or 0
$differenceEngine: DifferenceEngine object
$change: RecentChange object
$user: User object representing the current user
'DifferenceEngineNewHeader': Allows extensions to change the $newHeader
variable, which contains information about the new revision, such as the
revision's author, whether the revision was marked as a minor edit or not, etc.
$differenceEngine: DifferenceEngine object
&$newHeader: The string containing the various #mw-diff-otitle[1-5] divs, which
include things like revision author info, revision comment, RevisionDelete
link and more
$formattedRevisionTools: Array containing revision tools, some of which may have
been injected with the DiffRevisionTools hook
$nextlink: String containing the link to the next revision (if any); also
included in $newHeader
$rollback: Rollback link (string) to roll this revision back to the previous
one, if any
$newminor: String indicating if the new revision was marked as a minor edit
$diffOnly: Boolean parameter passed to DifferenceEngine#showDiffPage, indicating
whether we should show just the diff; passed in as a query string parameter to
the various URLs constructed here (i.e. $nextlink)
$rdel: RevisionDelete link for the new revision, if the current user is allowed
to use the RevisionDelete feature
$unhide: Boolean parameter indicating whether to show RevisionDeleted revisions
'DifferenceEngineOldHeader': Allows extensions to change the $oldHeader
variable, which contains information about the old revision, such as the
revision's author, whether the revision was marked as a minor edit or not, etc.
$differenceEngine: DifferenceEngine object
&$oldHeader: The string containing the various #mw-diff-otitle[1-5] divs, which
include things like revision author info, revision comment, RevisionDelete
link and more
$prevlink: String containing the link to the previous revision (if any); also
included in $oldHeader
$oldminor: String indicating if the old revision was marked as a minor edit
$diffOnly: Boolean parameter passed to DifferenceEngine#showDiffPage, indicating
whether we should show just the diff; passed in as a query string parameter to
the various URLs constructed here (i.e. $prevlink)
$ldel: RevisionDelete link for the old revision, if the current user is allowed
to use the RevisionDelete feature
$unhide: Boolean parameter indicating whether to show RevisionDeleted revisions
'DifferenceEngineOldHeaderNoOldRev': Change the $oldHeader variable in cases
when there is no old revision
&$oldHeader: empty string by default
'DifferenceEngineRenderRevisionAddParserOutput': Allows extensions to change the
parser output. Return false to not add parser output via OutputPage's
addParserOutput method.
$differenceEngine: DifferenceEngine object
$out: OutputPage object
$parserOutput: ParserOutput object
$wikiPage: WikiPage object
'DifferenceEngineRenderRevisionShowFinalPatrolLink': An extension can hook into
this hook point and return false to not show the final "mark as patrolled" link
on the bottom of a page.
This hook has no arguments.
'DifferenceEngineShowDiff': Allows extensions to affect the diff text which
eventually gets sent to the OutputPage object.
$differenceEngine: DifferenceEngine object
'DifferenceEngineShowEmptyOldContent': Allows extensions to change the diff
table body (without header) in cases when there is no old revision or the old
and new revisions are identical.
$differenceEngine: DifferenceEngine object
'DifferenceEngineShowDiffPage': Add additional output via the available
OutputPage object into the diff view
$out: OutputPage object
'DifferenceEngineShowDiffPageMaybeShowMissingRevision': called in
DifferenceEngine::showDiffPage() when revision data cannot be loaded.
Return false in order to prevent displaying the missing revision message
(i.e. to prevent DifferenceEngine::showMissingRevision() from being called).
$differenceEngine: DifferenceEngine object
'DiffRevisionTools': Override or extend the revision tools available from the
diff view, i.e. undo, etc.
$newRev: Revision object of the "new" revision
&$links: Array of HTML links
$oldRev: Revision object of the "old" revision (may be null)
$user: Current user object
'DiffViewHeader': Called before diff display
$diff: DifferenceEngine object that's calling
$oldRev: Revision object of the "old" revision (may be null/invalid)
$newRev: Revision object of the "new" revision
'DisplayOldSubtitle': before creating subtitle when browsing old versions of
an article
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$article: article (object) being viewed
&$oldid: oldid (int) being viewed
'EditFilter': Perform checks on an edit
$editor: EditPage instance (object). The edit form (see includes/EditPage.php)
$text: Contents of the edit box
$section: Section being edited
&$error: Error message to return
$summary: Edit summary for page
'EditFilterMergedContent': Post-section-merge edit filter.
This may be triggered by the EditPage or any other facility that modifies page
content. Use the $status object to indicate whether the edit should be allowed,
and to provide a reason for disallowing it. Return false to abort the edit, and
true to continue. Returning true if $status->isOK() returns false means "don't
save but continue user interaction", e.g. show the edit form.
$status->apiHookResult can be set to an array to be returned by api.php
action=edit. This is used to deliver captchas.
$context: object implementing the IContextSource interface.
$content: content of the edit box, as a Content object.
$status: Status object to represent errors, etc.
$summary: Edit summary for page
$user: the User object representing the user whois performing the edit.
$minoredit: whether the edit was marked as minor by the user.
'EditFormInitialText': Allows modifying the edit form when editing existing
pages
$editPage: EditPage object
'EditFormPreloadText': Allows population of the edit form when creating
new pages
&$text: Text to preload with
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object representing the page being created
'EditPage::attemptSave': Called before an article is
saved, that is before WikiPage::doEditContent() is called
$editpage_Obj: the current EditPage object
'EditPage::attemptSave:after': Called after an article save attempt
$editpage_Obj: the current EditPage object
$status: the resulting Status object
$resultDetails: Result details array
2009-07-08 18:47:46 +00:00
'EditPage::importFormData': allow extensions to read additional data
posted in the form
Return value is ignored (should always return true)
$editpage: EditPage instance
2009-07-08 18:47:46 +00:00
$request: Webrequest
'EditPage::showEditForm:fields': allows injection of form field into edit form
Return value is ignored (should always return true)
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$editor: the EditPage instance for reference
[&]$out: an OutputPage instance to write to
'EditPage::showEditForm:initial': before showing the edit form
Return false to halt editing; you'll need to handle error messages, etc.
yourself. Alternatively, modifying $error and returning true will cause the
contents of $error to be echoed at the top of the edit form as wikitext.
Return true without altering $error to allow the edit to proceed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$editor: EditPage instance (object)
[&]$out: an OutputPage instance to write to
'EditPage::showReadOnlyForm:initial': similar to EditPage::showEditForm:initial
but for the read-only 'view source' variant of the edit form.
Return value is ignored (should always return true)
$editor: EditPage instance (object)
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$out: an OutputPage instance to write to
'EditPage::showStandardInputs:options': allows injection of form fields into
the editOptions area
Return value is ignored (should always be true)
$editor: EditPage instance (object)
$out: an OutputPage instance to write to
&$tabindex: HTML tabindex of the last edit check/button
'EditPageBeforeConflictDiff': allows modifying the EditPage object and output
when there's an edit conflict. Return false to halt normal diff output; in
this case you're responsible for computing and outputting the entire "conflict"
part, i.e., the "difference between revisions" and "your text" headers and
sections.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$editor: EditPage instance
[&]$out: OutputPage instance
'EditPageBeforeEditButtons': Allows modifying the edit buttons below the
textarea in the edit form.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$editpage: The current EditPage object
&$buttons: Array of edit buttons "Save", "Preview", "Live", and "Diff"
&$tabindex: HTML tabindex of the last edit check/button
Remove old "bulletin board style toolbar" from core 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
2016-10-20 21:26:22 +00:00
'EditPageBeforeEditToolbar': Allow adding an edit toolbar above the textarea in
the edit form.
&$toolbar: The toolbar HTML, initially an empty `<div id="toolbar"></div>`
Hook subscribers can return false to have no toolbar HTML be loaded.
'EditPageCopyrightWarning': Allow for site and per-namespace customization of
contribution/copyright notice.
$title: title of page being edited
&$msg: localization message name, overridable. Default is either
'copyrightwarning' or 'copyrightwarning2'.
'EditPageGetCheckboxesDefinition': Allows modifying the edit checkboxes
below the textarea in the edit form.
$editpage: The current EditPage object
&$checkboxes: Array of checkbox definitions. See
EditPage::getCheckboxesDefinition() for the format.
'EditPageGetDiffContent': Allow modifying the wikitext that will be used in
"Show changes". Note that it is preferable to implement diff handling for
different data types using the ContentHandler facility.
$editPage: EditPage object
&$newtext: wikitext that will be used as "your version"
'EditPageGetPreviewContent': Allow modifying the wikitext that will be
previewed. Note that it is preferable to implement previews for different data
types using the ContentHandler facility.
$editPage: EditPage object
&$content: Content object to be previewed (may be replaced by hook function)
'EditPageNoSuchSection': When a section edit request is given for an
non-existent section
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$editpage: The current EditPage object
&$res: the HTML of the error text
'EditPageTosSummary': Give a chance for site and per-namespace customizations
of terms of service summary link that might exist separately from the copyright
notice.
$title: title of page being edited
&$msg: localization message name, overridable. Default is 'editpage-tos-summary'
'EmailConfirmed': When checking that the user's email address is "confirmed".
2006-05-02 20:07:54 +00:00
This runs before the other checks, such as anonymity and the real check; return
true to allow those checks to occur, and false if checking is done.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: User being checked
&$confirmed: Whether or not the email address is confirmed
2006-05-02 20:07:54 +00:00
'EmailUser': Before sending email from one user to another.
&$to: MailAddress object of receiving user
&$from: MailAddress object of sending user
&$subject: subject of the mail
&$text: text of the mail
&$error: Out-param for an error. Should be set to a Status object or boolean
false.
'EmailUserCC': Before sending the copy of the email to the author.
&$to: MailAddress object of receiving user
&$from: MailAddress object of sending user
&$subject: subject of the mail
&$text: text of the mail
2010-04-13 17:33:22 +00:00
'EmailUserComplete': After sending email from one user to another.
$to: MailAddress object of receiving user
$from: MailAddress object of sending user
$subject: subject of the mail
$text: text of the mail
'EmailUserForm': After building the email user form object.
&$form: HTMLForm object
2010-04-13 17:33:22 +00:00
'EmailUserPermissionsErrors': to retrieve permissions errors for emailing a
user.
$user: The user who is trying to email another user.
$editToken: The user's edit token.
&$hookErr: Out-param for the error. Passed as the parameters to
OutputPage::showErrorPage.
'EnhancedChangesList::getLogText': to alter, remove or add to the links of a
group of changes in EnhancedChangesList.
Hook subscribers can return false to omit this line from recentchanges.
$changesList: EnhancedChangesList object
&$links: The links that were generated by EnhancedChangesList
$block: The RecentChanges objects in that block
'EnhancedChangesListModifyLineData': to alter data used to build
a grouped recent change inner line in EnhancedChangesList.
Hook subscribers can return false to omit this line from recentchanges.
$changesList: EnhancedChangesList object
&$data: An array with all the components that will be joined in order to create
the line
$block: An array of RecentChange objects in that block
$rc: The RecentChange object for this line
&$classes: An array of classes to change
&$attribs: associative array of other HTML attributes for the <tr> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'EnhancedChangesListModifyBlockLineData': to alter data used to build
a non-grouped recent change line in EnhancedChangesList.
$changesList: EnhancedChangesList object
&$data: An array with all the components that will be joined in order to create
the line
$rc: The RecentChange object for this line
'ExemptFromAccountCreationThrottle': Exemption from the account creation
throttle.
$ip: The ip address of the user
'ExtensionTypes': Called when generating the extensions credits, use this to
change the tables headers.
&$extTypes: associative array of extensions types
'FetchChangesList': When fetching the ChangesList derivative for a particular
user.
$user: User the list is being fetched for
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$skin: Skin object to be used with the list
&$list: List object (defaults to NULL, change it to an object instance and
return false override the list derivative used)
$groups: Array of ChangesListFilterGroup objects (added in 1.34)
'FileDeleteComplete': When a file is deleted.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$file: reference to the deleted file
[&]$oldimage: in case of the deletion of an old image, the name of the old file
[&]$article: in case all revisions of the file are deleted a reference to the
WikiFilePage associated with the file.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user who performed the deletion
[&]$reason: reason
'FileTransformed': When a file is transformed and moved into storage.
$file: reference to the File object
$thumb: the MediaTransformOutput object
$tmpThumbPath: The temporary file system path of the transformed file
$thumbPath: The permanent storage path of the transformed file
'FileUndeleteComplete': When a file is undeleted
$title: title object to the file
$fileVersions: array of undeleted versions. Empty if all versions were restored
$user: user who performed the undeletion
$reason: reason
'FileUpload': When a file upload occurs.
$file: Image object representing the file that was uploaded
$reupload: Boolean indicating if there was a previously another image there or
not (since 1.17)
$hasDescription: Boolean indicating that there was already a description page
and a new one from the comment wasn't created (since 1.17)
'FormatAutocomments': When an autocomment is formatted by the Linker.
&$comment: Reference to the accumulated comment. Initially null, when set the
default code will be skipped.
$pre: Boolean, true if there is text before this autocomment
$auto: The extracted part of the parsed comment before the call to the hook.
$post: Boolean, true if there is text after this autocomment
$title: An optional title object used to links to sections. Can be null.
$local: Boolean indicating whether section links should refer to local page.
$wikiId: String containing the ID (as used by WikiMap) of the wiki from which the
autocomment originated; null for the local wiki. Added in 1.26, should default
to null in handler functions, for backwards compatibility.
New more slick gallery display This extension adds a "mode" parameter to the gallery tag, allowing different formats for the gallery tag (galleries in the ui can be controlled by a global) The added modes are: *traditional - The original gallery *nolines - Like the original, no borders, less padding *packed - All images aligned by having same height. JS also justifies the images. (I think this one is the one that will go over best with users.) *packed-overlay - like packed, but caption goes over top the image in a transloucent box. *packed-hover - like packed-overlay, but caption only visible on hover. Degrades gracefully on screen readers, and falls back to packed-overlay if you are using a touch screen. I kind of like this mode when the caption is not that important (ex a category where its just the file name). This also adds a hook to allow people to make their own gallery version. I believe there would be interest in this, as different people have done different experiments. For example: * Wikia: http://community.wikia.com/wiki/Help:Galleries,_Slideshows,_and_Sliders/wikitext * Wikinews: https://en.wikinews.org/wiki/Template:Picture_select What I would like to see for this patch, is first it gets enabled, with the default still "traditional". After about a month or two we consult with users. If feedback is positive, we change the default mode to one of the others (probably "packed"). Adds a "mode" parameter to gallery for different mode, including one 'height-constrained-overlay' which looks much more like other modern websites. Note: This makes one change to the old gallery format. It makes Nonexistent files be rendered like thumbnails (i.e. they are rendered with a little grey border). One thing I'm slightly worried about with this patch, is that I added an option to MediaTransformOutput::toHtml to override the width attribute. I'm not sure if that is the best approach, and would appreciate thoughts on that. This should be merged at the same time as Ie82c1548 Change-Id: I33462a8b52502ed76aeb163b66e3704c8618ba23
2013-06-08 04:47:07 +00:00
'GalleryGetModes': Get list of classes that can render different modes of a
gallery.
&$modeArray: An associative array mapping mode names to classes that implement
that mode. It is expected all registered classes are a subclass of
ImageGalleryBase.
New more slick gallery display This extension adds a "mode" parameter to the gallery tag, allowing different formats for the gallery tag (galleries in the ui can be controlled by a global) The added modes are: *traditional - The original gallery *nolines - Like the original, no borders, less padding *packed - All images aligned by having same height. JS also justifies the images. (I think this one is the one that will go over best with users.) *packed-overlay - like packed, but caption goes over top the image in a transloucent box. *packed-hover - like packed-overlay, but caption only visible on hover. Degrades gracefully on screen readers, and falls back to packed-overlay if you are using a touch screen. I kind of like this mode when the caption is not that important (ex a category where its just the file name). This also adds a hook to allow people to make their own gallery version. I believe there would be interest in this, as different people have done different experiments. For example: * Wikia: http://community.wikia.com/wiki/Help:Galleries,_Slideshows,_and_Sliders/wikitext * Wikinews: https://en.wikinews.org/wiki/Template:Picture_select What I would like to see for this patch, is first it gets enabled, with the default still "traditional". After about a month or two we consult with users. If feedback is positive, we change the default mode to one of the others (probably "packed"). Adds a "mode" parameter to gallery for different mode, including one 'height-constrained-overlay' which looks much more like other modern websites. Note: This makes one change to the old gallery format. It makes Nonexistent files be rendered like thumbnails (i.e. they are rendered with a little grey border). One thing I'm slightly worried about with this patch, is that I added an option to MediaTransformOutput::toHtml to override the width attribute. I'm not sure if that is the best approach, and would appreciate thoughts on that. This should be merged at the same time as Ie82c1548 Change-Id: I33462a8b52502ed76aeb163b66e3704c8618ba23
2013-06-08 04:47:07 +00:00
'GetAutoPromoteGroups': When determining which autopromote groups a user is
entitled to be in.
$user: user to promote.
&$promote: groups that will be added.
'GetCacheVaryCookies': Get cookies that should vary cache options.
2008-04-10 14:28:56 +00:00
$out: OutputPage object
&$cookies: array of cookies name, add a value to it if you want to add a cookie
that have to vary cache options
2008-04-10 14:28:56 +00:00
'GetCanonicalURL': Modify fully-qualified URLs used for IRC and e-mail
notifications.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object of page
&$url: string value as output (out parameter, can modify)
$query: query options as string passed to Title::getCanonicalURL()
'GetContentModels': Add content models to the list of available models.
&$models: array containing current model list, as strings. Extensions should add to this list.
'GetDefaultSortkey': Override the default sortkey for a page.
$title: Title object that we need to get a sortkey for
&$sortkey: Sortkey to use.
'GetDifferenceEngine': Called when getting a new difference engine interface
object. Can be used to decorate or replace the default difference engine.
$context: IContextSource context to be used for diff
$old: Revision ID to show and diff with
$new: Either a revision ID or one of the strings 'cur', 'prev' or 'next'
$refreshCache: If set, refreshes the diff cache
$unhide: If set, allow viewing deleted revs
&$differenceEngine: The difference engine object to be used for the diff
'GetDoubleUnderscoreIDs': Modify the list of behavior switch (double
underscore) magic words. Called by MagicWord.
&$doubleUnderscoreIDs: array of strings
'GetExtendedMetadata': Get extended file metadata for the API
&$combinedMeta: Array of the form:
'MetadataPropName' => [
value' => prop value,
'source' => 'name of hook'
].
$file: File object of file in question
$context: RequestContext (including language to use)
$single: Only extract the current language; if false, the prop value should
be in the metadata multi-language array format:
mediawiki.org/wiki/Manual:File_metadata_handling#Multi-language_array_format
&$maxCacheTime: how long the results can be cached
'GetFullURL': Modify fully-qualified URLs used in redirects/export/offsite data.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object of page
&$url: string value as output (out parameter, can modify)
$query: query options as string passed to Title::getFullURL()
'GetHumanTimestamp': Pre-emptively override the human-readable timestamp
generated by MWTimestamp::getHumanTimestamp(). Return false in this hook to use
the custom output.
&$output: string for the output timestamp
$timestamp: MWTimestamp object of the current (user-adjusted) timestamp
$relativeTo: MWTimestamp object of the relative (user-adjusted) timestamp
$user: User whose preferences are being used to make timestamp
$lang: Language that will be used to render the timestamp
'GetInternalURL': Modify fully-qualified URLs used for squid cache purging.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object of page
&$url: string value as output (out parameter, can modify)
$query: query options as string passed to Title::getInternalURL()
'GetIP': modify the ip of the current user (called only once).
&$ip: string holding the ip as determined so far
'GetLangPreferredVariant': Called in LanguageConverter#getPreferredVariant() to
allow fetching the language variant code from cookies or other such
alternative storage.
&$req: language variant from the URL (string) or boolean false if no variant
was specified in the URL; the value of this variable comes from
LanguageConverter#getURLVariant()
'GetLinkColours': modify the CSS class of an array of page links.
$linkcolour_ids: array of prefixed DB keys of the pages linked to,
indexed by page_id.
&$colours: (output) array of CSS classes, indexed by prefixed DB keys
$title: Title object of the page being parsed, on which the links will be shown
'GetLocalURL': Modify local URLs as output into page links. Note that if you are
working with internal urls (non-interwiki) then it may be preferable to work
with the GetLocalURL::Internal or GetLocalURL::Article hooks as GetLocalURL can
be buggy for internal urls on render if you do not re-implement the horrible
hack that Title::getLocalURL uses in your own extension.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object of page
&$url: string value as output (out parameter, can modify)
$query: query options as string passed to Title::getLocalURL()
'GetLocalURL::Article': Modify local URLs specifically pointing to article paths
without any fancy queries or variants.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object of page
&$url: string value as output (out parameter, can modify)
'GetLocalURL::Internal': Modify local URLs to internal pages.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object of page
&$url: string value as output (out parameter, can modify)
$query: query options as string passed to Title::getLocalURL()
'GetLogTypesOnUser': Add log types where the target is a userpage
&$types: Array of log types
'GetMetadataVersion': Modify the image metadata version currently in use. This
is used when requesting image metadata from a ForeignApiRepo. Media handlers
that need to have versioned metadata should add an element to the end of the
version array of the form 'handler_name=version'. Most media handlers won't need
to do this unless they broke backwards compatibility with a previous version of
the media handler metadata output.
&$version: Array of version strings
'GetNewMessagesAlert': Disable or modify the new messages alert
&$newMessagesAlert: An empty string by default. If the user has new talk page
messages, this should be populated with an alert message to that effect
$newtalks: An empty array if the user has no new messages or an array
containing links and revisions if there are new messages (See
User::getNewMessageLinks)
$user: The user object of the user who is loading the page
$out: OutputPage object (to check what type of page the user is on)
'GetPreferences': Modify user preferences.
$user: User whose preferences are being modified.
&$preferences: Preferences description array, to be fed to an HTMLForm object
'GetRelativeTimestamp': Pre-emptively override the relative timestamp generated
by MWTimestamp::getRelativeTimestamp(). Return false in this hook to use the
custom output.
&$output: string for the output timestamp
&$diff: DateInterval representing the difference between the timestamps
$timestamp: MWTimestamp object of the current (user-adjusted) timestamp
$relativeTo: MWTimestamp object of the relative (user-adjusted) timestamp
$user: User whose preferences are being used to make timestamp
$lang: Language that will be used to render the timestamp
[MCR] Render multi-slot diffs 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
2018-07-11 09:24:07 +00:00
'GetSlotDiffRenderer': Replace or wrap the standard SlotDiffRenderer for some
content type.
$contentHandler: ContentHandler for which the slot diff renderer is fetched.
&$slotDiffRenderer: SlotDiffRenderer to change or replace.
$context: IContextSource
'GetUserBlock': Modify the block found by the block manager. This may be a
single block or a composite block made from multiple blocks; the original
blocks can be seen using CompositeBlock::getOriginalBlocks()
$user: User targeted by the block
$ip: string|null The IP of the current request if $user is the current user
and they're not exempted from IP blocks. Null otherwise.
&$block: AbstractBlock|null The user's block, or null if none was found.
'getUserPermissionsErrors': Add a permissions error when permissions errors are
checked for. Use instead of userCan for most cases. Return false if the user
can't do it, and populate $result with the reason in the form of
[ messagename, param1, param2, ... ] or a MessageSpecifier instance (you
might want to use ApiMessage to provide machine-readable details for the API).
For consistency, error messages
should be plain text with no special coloring, bolding, etc. to show that
they're errors; presenting them properly to the user as errors is done by the
caller.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object being checked against
[&]$user: Current user object
$action: Action being checked
&$result: User permissions error to add. If none, return true.
'getUserPermissionsErrorsExpensive': Equal to getUserPermissionsErrors, but is
called only if expensive checks are enabled. Add a permissions error when
permissions errors are checked for. Return false if the user can't do it, and
populate $result with the reason in the form of [ messagename, param1, param2,
... ] or a MessageSpecifier instance (you might want to use ApiMessage to
provide machine-readable details for the API). For consistency, error messages
should be plain text with no special coloring, bolding, etc. to show that
they're errors; presenting them properly to the user as errors is done by the
caller.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object being checked against
[&]$user: Current user object
$action: Action being checked
&$result: User permissions error to add. If none, return true.
'GitViewers': Called when generating the list of git viewers for
Special:Version, use this to change the list.
&$extTypes: associative array of repo URLS to viewer URLs.
'HistoryRevisionTools': Override or extend the revision tools available from the
page history view, i.e. undo, rollback, etc.
$rev: Revision object
&$links: Array of HTML links
$prevRev: Revision object, next in line in page history, or null
$user: Current user object
'HistoryPageToolLinks': Add one or more links to revision history page subtitle.
$context: IContextSource (object)
$linkRenderer: LinkRenderer instance
&$links: Array of HTML strings
'HTMLFileCache::useFileCache': Override whether a page should be cached in file
cache.
$context: An IContextSource object with information about the request being
served.
'ImageBeforeProduceHTML': Called before producing the HTML created by a wiki
image insertion. You can skip the default logic entirely by returning false, or
just modify a few things using call-by-reference.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$skin: Skin object
&$title: Title object of the image
&$file: File object, or false if it doesn't exist
&$frameParams: Various parameters with special meanings; see documentation in
includes/Linker.php for Linker::makeImageLink
&$handlerParams: Various parameters with special meanings; see documentation in
includes/Linker.php for Linker::makeImageLink
&$time: Timestamp of file in 'YYYYMMDDHHIISS' string form, or false for current
&$res: Final HTML output, used if you return false
$parser: Parser instance
&$query: Query params for desc URL
&$widthOption: Used by the parser to remember the user preference thumbnailsize
'ImageOpenShowImageInlineBefore': Call potential extension just before showing
the image on an image page.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$imagePage: ImagePage object ($this)
[&]$output: $wgOut
'ImagePageAfterImageLinks': Called after the image links section on an image
page is built.
$imagePage: ImagePage object ($this)
&$html: HTML for the hook to add
'ImagePageFileHistoryLine': Called when a file history line is constructed.
$imagePage: ImagePage object ($this)
$file: the file
&$line: the HTML of the history line
&$css: the line CSS class
'ImagePageFindFile': Called when fetching the file associated with an image
page.
2008-05-24 20:51:08 +00:00
$page: ImagePage object
&$file: File object
&$displayFile: displayed File object
'ImagePageShowTOC': Called when the file toc on an image page is generated.
$page: ImagePage object
&$toc: Array of <li> strings
'ImgAuthBeforeStream': Executed before file is streamed to user, but only when
using img_auth.php.
&$title: the Title object of the file as it would appear for the upload page
&$path: the original file and path name when img_auth was invoked by the web
server
&$name: the name only component of the file
&$result: The location to pass back results of the hook routine (only used if
failed)
$result[0]=The index of the header message
$result[1]=The index of the body text message
$result[2 through n]=Parameters passed to body text message. Please note the
header message cannot receive/use parameters.
'ImgAuthModifyHeaders': Executed just before a file is streamed to a user via
img_auth.php, allowing headers to be modified beforehand.
$title: LinkTarget object
&$headers: HTTP headers ( name => value, names are case insensitive ).
Two headers get special handling: If-Modified-Since (value must be
a valid HTTP date) and Range (must be of the form "bytes=(\d*-\d*)")
will be honored when streaming the file.
'ImportHandleLogItemXMLTag': When parsing a XML tag in a log item.
Return false to stop further processing of the tag
2010-07-03 14:33:09 +00:00
$reader: XMLReader object
$logInfo: Array of information
'ImportHandlePageXMLTag': When parsing a XML tag in a page.
Return false to stop further processing of the tag
2010-07-03 14:33:09 +00:00
$reader: XMLReader object
&$pageInfo: Array of information
2010-07-03 14:33:09 +00:00
'ImportHandleRevisionXMLTag': When parsing a XML tag in a page revision.
Return false to stop further processing of the tag
2010-07-03 14:33:09 +00:00
$reader: XMLReader object
$pageInfo: Array of page information
$revisionInfo: Array of revision information
2010-07-03 14:33:09 +00:00
'ImportHandleToplevelXMLTag': When parsing a top level XML tag.
2010-07-03 14:33:09 +00:00
Return false to stop further processing of the tag
$reader: XMLReader object
2010-07-03 14:33:09 +00:00
'ImportHandleUnknownUser': When a user doesn't exist locally, this hook is
called to give extensions an opportunity to auto-create it. If the auto-creation
is successful, return false.
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
$name: User name
'ImportHandleUploadXMLTag': When parsing a XML tag in a file upload.
Return false to stop further processing of the tag
2010-07-03 14:33:09 +00:00
$reader: XMLReader object
$revisionInfo: Array of information
'ImportLogInterwikiLink': Hook to change the interwiki link used in log entries
and edit summaries for transwiki imports.
&$fullInterwikiPrefix: Interwiki prefix, may contain colons.
&$pageTitle: String that contains page title.
'ImportSources': Called when reading from the $wgImportSources configuration
variable. Can be used to lazy-load the import sources list.
&$importSources: The value of $wgImportSources. Modify as necessary. See the
comment in DefaultSettings.php for the detail of how to structure this array.
'InfoAction': When building information to display on the action=info page.
$context: IContextSource object
&$pageInfo: Array of information
'InitializeArticleMaybeRedirect': MediaWiki check to see if title is a redirect.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object for the current page
[&]$request: WebRequest
&$ignoreRedirect: boolean to skip redirect check
&$target: Title/string of redirect target
&$article: Article object
2008-07-04 09:38:12 +00:00
'InternalParseBeforeLinks': during Parser's internalParse method before links
but after nowiki/noinclude/includeonly/onlyinclude and other processings.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
&$text: string containing partially parsed text
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$stripState: Parser's internal StripState object
2011-03-17 15:51:19 +00:00
'InternalParseBeforeSanitize': DEPRECATED since 1.35!
During Parser's internalParse method just before
the parser removes unwanted/dangerous HTML tags and after nowiki/noinclude/
includeonly/onlyinclude and other processings. Ideal for syntax-extensions after
template/parser function execution which respect nowiki and HTML-comments.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
&$text: string containing partially parsed text
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$stripState: Parser's internal StripState object
'InterwikiLoadPrefix': When resolving if a given prefix is an interwiki or not.
Return true without providing an interwiki to continue interwiki search.
$prefix: interwiki prefix we are looking for.
&$iwData: output array describing the interwiki with keys iw_url, iw_local,
iw_trans and optionally iw_api and iw_wikiid.
'InvalidateEmailComplete': Called after a user's email has been invalidated
successfully.
$user: user (object) whose email is being invalidated
'IRCLineURL': When constructing the URL to use in an IRC notification.
Callee may modify $url and $query, URL will be constructed as $url . $query
&$url: URL to index.php
&$query: Query string
$rc: RecentChange object that triggered url generation
'IsFileCacheable': Override the result of Article::isFileCacheable() (if true)
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$article: article (object) being checked
'IsTrustedProxy': Override the result of ProxyLookup::isTrustedProxy()
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$ip: IP being check
&$result: Change this value to override the result of ProxyLookup::isTrustedProxy()
'IsUploadAllowedFromUrl': Override the result of UploadFromUrl::isAllowedUrl()
$url: URL used to upload from
&$allowed: Boolean indicating if uploading is allowed for given URL
'isValidEmailAddr': Override the result of Sanitizer::validateEmail(), for
instance to return false if the domain name doesn't match your organization.
$addr: The e-mail address entered by the user
&$result: Set this and return false to override the internal checks
'isValidPassword': Override the result of User::isValidPassword()
$password: The password entered by the user
&$result: Set this and return false to override the internal checks
$user: User the password is being validated for
'Language::getMessagesFileName':
$code: The language code or the language we're looking for a messages file for
&$file: The messages file path, you can override this to change the location.
'LanguageGetNamespaces': Provide custom ordering for namespaces or
remove namespaces. Do not use this hook to add namespaces. Use
CanonicalNamespaces for that.
&$namespaces: Array of namespaces indexed by their numbers
'LanguageGetTranslatedLanguageNames': Provide translated language names.
&$names: array of language code => language name
$code: language of the preferred translations
'LanguageLinks': Manipulate a page's language links. This is called
in various places to allow extensions to define the effective language
links for a page.
$title: The page's Title.
&$links: Array with elements of the form "language:title" in the order
that they will be output.
&$linkFlags: Associative array mapping prefixed links to arrays of flags.
Currently unused, but planned to provide support for marking individual
language links in the UI, e.g. for featured articles.
'LanguageSelector': Hook to change the language selector available on a page.
$out: The output page.
$cssClassName: CSS class name of the language selector.
'LinkBegin': DEPRECATED since 1.28! Use HtmlPageLinkRendererBegin instead.
Used when generating internal and interwiki links in Linker::link(), before
processing starts. Return false to skip default processing and return $ret. See
documentation for Linker::link() for details on the expected meanings of
parameters.
$skin: the Skin object
$target: the Title that the link is pointing to
&$html: the contents that the <a> tag should have (raw HTML); null means
"default".
&$customAttribs: the HTML attributes that the <a> tag should have, in
associative array form, with keys and values unescaped. Should be merged
with default values, with a value of false meaning to suppress the
attribute.
&$query: the query string to add to the generated URL (the bit after the "?"),
in associative array form, with keys and values unescaped.
&$options: array of options. Can include 'known', 'broken', 'noclasses'.
&$ret: the value to return if your hook returns false.
'LinkEnd': DEPRECATED since 1.28! Use HtmlPageLinkRendererEnd hook instead
Add LinkRenderer (rewrite of Linker::link()) This is a rewrite of Linker::link() to a non-static, LinkTarget-based interface. Users of plain Linker::link() with no options can use the LinkRenderer instance provided by MediaWikiServices. Others that have specific options should create and configure their own instance, which can be used to create as many links as necessary. The main entrypoints for making links are: * ->makeLink( $target, $text, $attribs, $query ); * ->makeKnownLink( $target, $text, $attribs, $query ); * ->makeBrokenLink( $target, $text, $attribs, $query ); The order of the parameters are the same as Linker::link(), except $options are now part of the LinkRenderer instance, and known/broken status requires calling the function explicitly. Additionally, instead of passing in raw $html for the link text, the $text parameter will automatically be escaped unless it is specially marked as safe HTML using the MediaWiki\Linker\HtmlArmor class. The LinkBegin and LinkEnd hooks are now deprecated, but still function for backwards-compatability. Clients should migrate to the nearly- equivalent LinkRendererBegin and LinkRendererEnd hooks. The main differences between the hooks are: * Passing HtmlPageLinkRenderer object instead of deprecated DummyLinker * Using LinkTarget instead of Title * Begin hook can no longer change known/broken status of link. Use the TitleIsAlwaysKnown hook for that. * $options are no longer passed, they can be read (but shouldn't be modified!) from the LinkRenderer object. Bug: T469 Change-Id: I057cc86ae6404a080aa3c8e0e956ecbb10a897d5
2016-04-21 20:13:21 +00:00
Used when generating internal and interwiki links in Linker::link(),
just before the function returns a value. If you return true, an <a> element
with HTML attributes $attribs and contents $html will be returned. If you
return false, $ret will be returned.
$skin: the Skin object
$target: the Title object that the link is pointing to
$options: the options. Will always include either 'known' or 'broken', and may
include 'noclasses'.
2011-05-09 02:55:17 +00:00
&$html: the final (raw HTML) contents of the <a> tag, after processing.
&$attribs: the final HTML attributes of the <a> tag, after processing, in
associative array form.
&$ret: the value to return if your hook returns false.
'LinkerMakeExternalImage': At the end of Linker::makeExternalImage() just
before the return.
&$url: the image url
2008-07-02 01:05:08 +00:00
&$alt: the image's alt text
&$img: the new image HTML (if returning false)
'LinkerMakeExternalLink': At the end of Linker::makeExternalLink() just
before the return.
&$url: the link url
&$text: the link text
&$link: the new link HTML (if returning false)
&$attribs: the attributes to be applied.
$linkType: The external link type
'LinkerMakeMediaLinkFile': At the end of Linker::makeMediaLinkFile() just
before the return.
$title: the Title object that the link is pointing to
$file: the File object or false if broken link
&$html: the link text
&$attribs: the attributes to be applied
&$ret: the value to return if your hook returns false
'LogEventsListLineEnding': Called before a Special:Log line is finished
$page: the LogEventsList object
&$ret: the HTML line
$entry: the DatabaseLogEntry object for this row
&$classes: the classes to add to the surrounding <li>
&$attribs: associative array of other HTML attributes for the <li> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'HtmlPageLinkRendererBegin':
Add LinkRenderer (rewrite of Linker::link()) This is a rewrite of Linker::link() to a non-static, LinkTarget-based interface. Users of plain Linker::link() with no options can use the LinkRenderer instance provided by MediaWikiServices. Others that have specific options should create and configure their own instance, which can be used to create as many links as necessary. The main entrypoints for making links are: * ->makeLink( $target, $text, $attribs, $query ); * ->makeKnownLink( $target, $text, $attribs, $query ); * ->makeBrokenLink( $target, $text, $attribs, $query ); The order of the parameters are the same as Linker::link(), except $options are now part of the LinkRenderer instance, and known/broken status requires calling the function explicitly. Additionally, instead of passing in raw $html for the link text, the $text parameter will automatically be escaped unless it is specially marked as safe HTML using the MediaWiki\Linker\HtmlArmor class. The LinkBegin and LinkEnd hooks are now deprecated, but still function for backwards-compatability. Clients should migrate to the nearly- equivalent LinkRendererBegin and LinkRendererEnd hooks. The main differences between the hooks are: * Passing HtmlPageLinkRenderer object instead of deprecated DummyLinker * Using LinkTarget instead of Title * Begin hook can no longer change known/broken status of link. Use the TitleIsAlwaysKnown hook for that. * $options are no longer passed, they can be read (but shouldn't be modified!) from the LinkRenderer object. Bug: T469 Change-Id: I057cc86ae6404a080aa3c8e0e956ecbb10a897d5
2016-04-21 20:13:21 +00:00
Used when generating internal and interwiki links in
LinkRenderer, before processing starts. Return false to skip default
processing and return $ret.
$linkRenderer: the LinkRenderer object
$target: the LinkTarget that the link is pointing to
&$text: the contents that the <a> tag should have; either a plain, unescaped
string or a HtmlArmor object; null means "default".
Add LinkRenderer (rewrite of Linker::link()) This is a rewrite of Linker::link() to a non-static, LinkTarget-based interface. Users of plain Linker::link() with no options can use the LinkRenderer instance provided by MediaWikiServices. Others that have specific options should create and configure their own instance, which can be used to create as many links as necessary. The main entrypoints for making links are: * ->makeLink( $target, $text, $attribs, $query ); * ->makeKnownLink( $target, $text, $attribs, $query ); * ->makeBrokenLink( $target, $text, $attribs, $query ); The order of the parameters are the same as Linker::link(), except $options are now part of the LinkRenderer instance, and known/broken status requires calling the function explicitly. Additionally, instead of passing in raw $html for the link text, the $text parameter will automatically be escaped unless it is specially marked as safe HTML using the MediaWiki\Linker\HtmlArmor class. The LinkBegin and LinkEnd hooks are now deprecated, but still function for backwards-compatability. Clients should migrate to the nearly- equivalent LinkRendererBegin and LinkRendererEnd hooks. The main differences between the hooks are: * Passing HtmlPageLinkRenderer object instead of deprecated DummyLinker * Using LinkTarget instead of Title * Begin hook can no longer change known/broken status of link. Use the TitleIsAlwaysKnown hook for that. * $options are no longer passed, they can be read (but shouldn't be modified!) from the LinkRenderer object. Bug: T469 Change-Id: I057cc86ae6404a080aa3c8e0e956ecbb10a897d5
2016-04-21 20:13:21 +00:00
&$customAttribs: the HTML attributes that the <a> tag should have, in
associative array form, with keys and values unescaped. Should be merged
with default values, with a value of false meaning to suppress the
attribute.
&$query: the query string to add to the generated URL (the bit after the "?"),
in associative array form, with keys and values unescaped.
&$ret: the value to return if your hook returns false.
'HtmlPageLinkRendererEnd':
Add LinkRenderer (rewrite of Linker::link()) This is a rewrite of Linker::link() to a non-static, LinkTarget-based interface. Users of plain Linker::link() with no options can use the LinkRenderer instance provided by MediaWikiServices. Others that have specific options should create and configure their own instance, which can be used to create as many links as necessary. The main entrypoints for making links are: * ->makeLink( $target, $text, $attribs, $query ); * ->makeKnownLink( $target, $text, $attribs, $query ); * ->makeBrokenLink( $target, $text, $attribs, $query ); The order of the parameters are the same as Linker::link(), except $options are now part of the LinkRenderer instance, and known/broken status requires calling the function explicitly. Additionally, instead of passing in raw $html for the link text, the $text parameter will automatically be escaped unless it is specially marked as safe HTML using the MediaWiki\Linker\HtmlArmor class. The LinkBegin and LinkEnd hooks are now deprecated, but still function for backwards-compatability. Clients should migrate to the nearly- equivalent LinkRendererBegin and LinkRendererEnd hooks. The main differences between the hooks are: * Passing HtmlPageLinkRenderer object instead of deprecated DummyLinker * Using LinkTarget instead of Title * Begin hook can no longer change known/broken status of link. Use the TitleIsAlwaysKnown hook for that. * $options are no longer passed, they can be read (but shouldn't be modified!) from the LinkRenderer object. Bug: T469 Change-Id: I057cc86ae6404a080aa3c8e0e956ecbb10a897d5
2016-04-21 20:13:21 +00:00
Used when generating internal and interwiki links in LinkRenderer,
just before the function returns a value. If you return true, an <a> element
with HTML attributes $attribs and contents $html will be returned. If you
return false, $ret will be returned.
$linkRenderer: the LinkRenderer object
$target: the LinkTarget object that the link is pointing to
$isKnown: boolean indicating whether the page is known or not
&$text: the contents that the <a> tag should have; either a plain, unescaped
string or a HtmlArmor object.
Add LinkRenderer (rewrite of Linker::link()) This is a rewrite of Linker::link() to a non-static, LinkTarget-based interface. Users of plain Linker::link() with no options can use the LinkRenderer instance provided by MediaWikiServices. Others that have specific options should create and configure their own instance, which can be used to create as many links as necessary. The main entrypoints for making links are: * ->makeLink( $target, $text, $attribs, $query ); * ->makeKnownLink( $target, $text, $attribs, $query ); * ->makeBrokenLink( $target, $text, $attribs, $query ); The order of the parameters are the same as Linker::link(), except $options are now part of the LinkRenderer instance, and known/broken status requires calling the function explicitly. Additionally, instead of passing in raw $html for the link text, the $text parameter will automatically be escaped unless it is specially marked as safe HTML using the MediaWiki\Linker\HtmlArmor class. The LinkBegin and LinkEnd hooks are now deprecated, but still function for backwards-compatability. Clients should migrate to the nearly- equivalent LinkRendererBegin and LinkRendererEnd hooks. The main differences between the hooks are: * Passing HtmlPageLinkRenderer object instead of deprecated DummyLinker * Using LinkTarget instead of Title * Begin hook can no longer change known/broken status of link. Use the TitleIsAlwaysKnown hook for that. * $options are no longer passed, they can be read (but shouldn't be modified!) from the LinkRenderer object. Bug: T469 Change-Id: I057cc86ae6404a080aa3c8e0e956ecbb10a897d5
2016-04-21 20:13:21 +00:00
&$attribs: the final HTML attributes of the <a> tag, after processing, in
associative array form.
&$ret: the value to return if your hook returns false.
'LinksUpdate': At the beginning of LinksUpdate::doUpdate() just before the
actual update.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$linksUpdate: the LinksUpdate object
'LinksUpdateAfterInsert': At the end of LinksUpdate::incrTableUpdate() after
each link table insert. For example, pagelinks, imagelinks, externallinks.
$linksUpdate: LinksUpdate object
$table: the table to insert links to
$insertions: an array of links to insert
'LinksUpdateComplete': At the end of LinksUpdate::doUpdate() when updating,
including delete and insert, has completed for all link tables
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$linksUpdate: the LinksUpdate object
$ticket: prior result of LBFactory::getEmptyTransactionTicket()
'LinksUpdateConstructed': At the end of LinksUpdate() is construction.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$linksUpdate: the LinksUpdate object
'ListDefinedTags': When trying to find all defined tags.
&$tags: The list of tags.
'LoadExtensionSchemaUpdates': Called during database installation and updates.
$updater: A DatabaseUpdater subclass
'LocalFile::getHistory': Called before file history query performed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$file: the File object
&$tables: tables
&$fields: select fields
&$conds: conditions
&$opts: query options
&$join_conds: JOIN conditions
'LocalFilePurgeThumbnails': Called before thumbnails for a local file a purged.
$file: the File object
$archiveName: name of an old file version or false if it's the current one
'LocalisationCacheRecache': Called when loading the localisation data into
cache.
2009-07-19 20:03:13 +00:00
$cache: The LocalisationCache object
$code: language code
&$alldata: The localisation data from core and extensions
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$unused: Used to be $purgeBlobs, removed in 1.34
2009-07-19 20:03:13 +00:00
'LocalisationCacheRecacheFallback': Called for each language when merging
fallback data into the cache.
$cache: The LocalisationCache object
$code: language code
&$alldata: The localisation data from core and extensions. Note some keys may
be omitted if they won't be merged into the final result.
'LocalisationChecksBlacklist': When fetching the blacklist of
localisation checks.
&$blacklist: array of checks to blacklist. See the bottom of
maintenance/language/checkLanguage.inc for the format of this variable.
'LocalisationIgnoredOptionalMessages': When fetching the list of ignored and
optional localisation messages
&$ignored: Array of ignored message keys
&$optional: Array of optional message keys
'LocalUserCreated': Called when a local user has been created
$user: User object for the created user
$autocreated: Boolean, whether this was an auto-creation
'LogEventsListGetExtraInputs': When getting extra inputs to display on
Special:Log for a specific log type
$type: String of log type being displayed
$logEventsList: LogEventsList object for context and access to the WebRequest
&$input: string HTML of an input element (deprecated, use $formDescriptor instead)
&$formDescriptor: array HTMLForm's form descriptor
'LogEventsListShowLogExtract': Called before the string is added to OutputPage.
Returning false will prevent the string from being added to the OutputPage.
&$s: html string to show for the log extract
$types: String or Array Log types to show
$page: String or Title The page title to show log entries for
$user: String The user who made the log entries
$param: Associative Array with the following additional options:
- lim Integer Limit of items to show, default is 50
- conds Array Extra conditions for the query (e.g. "log_action != 'revision'")
- showIfEmpty boolean Set to false if you don't want any output in case the
loglist is empty if set to true (default), "No matching items in log" is
displayed if loglist is empty
- msgKey Array If you want a nice box with a message, set this to the key of
the message. First element is the message key, additional optional elements
are parameters for the key that are processed with
wfMessage()->params()->parseAsBlock()
- offset Set to overwrite offset parameter in $wgRequest set to '' to unset
offset
- wrap String Wrap the message in html (usually something like
"&lt;div ...>$1&lt;/div>").
- flags Integer display flags (NO_ACTION_LINK,NO_EXTRA_USER_LINKS)
'LogException': Called before an exception (or PHP error) is logged. This is
meant for integration with external error aggregation services; returning false
will NOT prevent logging.
$e: The exception (in case of a plain old PHP error, a wrapping ErrorException)
$suppressed: true if the error was suppressed via
error_reporting()/wfSuppressWarnings()
'LoginFormValidErrorMessages': Called in LoginForm when a function gets valid
error messages. Allows to add additional error messages (except messages already
in LoginForm::$validErrorMessages).
&$messages: Already added messages (inclusive messages from
LoginForm::$validErrorMessages)
'LogLine': Processes a single log entry on Special:Log.
$log_type: string for the type of log entry (e.g. 'move'). Corresponds to
logging.log_type database field.
$log_action: string for the type of log action (e.g. 'delete', 'block',
'create2'). Corresponds to logging.log_action database field.
$title: Title object that corresponds to logging.log_namespace and
logging.log_title database fields.
$paramArray: Array of parameters that corresponds to logging.log_params field.
Note that only $paramArray[0] appears to contain anything.
&$comment: string that corresponds to logging.log_comment database field, and
which is displayed in the UI.
&$revert: string that is displayed in the UI, similar to $comment.
$time: timestamp of the log entry (added in 1.12)
'LonelyPagesQuery': Allow extensions to modify the query used by
Special:LonelyPages.
&$tables: tables to join in the query
&$conds: conditions for the query
&$joinConds: join conditions for the query
'MagicWordwgVariableIDs': When defining new magic words IDs.
&$variableIDs: array of strings
'MaintenanceUpdateAddParams': allow extensions to add params to the update.php
maintenance script.
&$params: array to populate with the params to be added. Array elements are keyed by
the param name. Each param is an associative array that must include the following keys:
- desc The description of the param to show on --help
- require Is the param required? Defaults to false if not set.
- withArg Is an argument required with this option? Defaults to false if not set.
- shortName Character to use as short name, or false if none. Defaults to false if not set.
- multiOccurrence Can this option be passed multiple times? Defaults to false if not set.
'MaintenanceRefreshLinksInit': before executing the refreshLinks.php maintenance
script.
$refreshLinks: RefreshLinks object
'MakeGlobalVariablesScript': Called at end of OutputPage::getJSVars.
Ideally, this hook should only be used to add variables that depend on
the current page/request; static configuration should be added through
ResourceLoaderGetConfigVars instead.
&$vars: variable (or multiple variables) to be added into the output of
Skin::makeVariablesScript
$out: The OutputPage which called the hook, can be used to get the real title.
'ManualLogEntryBeforePublish': Allows to access or modify log entry just before it is
published.
$logEntry: ManualLogEntry object
'MarkPatrolled': Before an edit is marked patrolled.
$rcid: ID of the revision to be marked patrolled
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: the user (object) marking the revision as patrolled
$wcOnlySysopsCanPatrol: config setting indicating whether the user needs to be a
sysop in order to mark an edit patrolled.
$auto: true if the edit is being marked as patrolled automatically
&$tags: the tags to be applied to the patrol log entry
'MarkPatrolledComplete': After an edit is marked patrolled.
$rcid: ID of the revision marked as patrolled
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user (object) who marked the edit patrolled
$wcOnlySysopsCanPatrol: config setting indicating whether the user must be a
sysop to patrol the edit.
$auto: true if the edit is being marked as patrolled automatically
'ApiMaxLagInfo': When lag information is being requested via API. Use this to
override lag information. Generally a hook function should only replace
$lagInfo if the new $lagInfo['lag'] is greater than the current $lagInfo['lag'].
&$lagInfo: Maximum lag information array. Fields in the array are:
'lag' is the number of seconds of lag.
'host' is the host name on which the lag exists.
'type' is an indication of the type of lag,
e.g. "db" for database replication lag or "jobqueue" for job queue size
converted to pseudo-seconds.
It is possible to add more fields and they will be returned to the user in
the API response.
'MediaWikiPerformAction': Override MediaWiki::performAction(). Use this to do
something completely different, after the basic globals have been set up, but
before ordinary actions take place.
$output: Context output
$article: Article on which the action will be performed
$title: Title on which the action will be performed
$user: Context user
$request: Context request
$mediaWiki: The $mediawiki object
'MediaWikiPHPUnitTest::startTest': Before each PHPUnit test starts
$test: PHPUnit\Framework\Test object
'MediaWikiPHPUnitTest::endTest': After each PHPUnit test completes
$test: PHPUnit\Framework\Test object
$time: The execution time in seconds
'MediaWikiServices': Called when a global MediaWikiServices instance is
initialized. Extensions may use this to define, replace, or wrap services.
However, the preferred way to define a new service is
the $wgServiceWiringFiles array.
$services: MediaWikiServices
'MessageCache::get': When fetching a message. Can be used to override the key
for customisations. Given and returned message key must be in special format:
1) first letter must be in lower case according to the content language.
2) spaces must be replaced with underscores
&$key: message key (string)
'MessageCacheReplace': When a message page is changed. Useful for updating
caches.
$title: name of the page changed.
$text: new contents of the page.
'MessagesPreLoad': When loading a message from the database.
$title: title of the message (string)
&$message: value (string), change it to the message you want to define
$code: code (string) denoting the language to try.
'MimeMagicGuessFromContent': Allows MW extensions guess the MIME by content.
$mimeMagic: Instance of MimeAnalyzer.
&$head: First 1024 bytes of the file in a string (in - Do not alter!).
&$tail: More or equal than last 65558 bytes of the file in a string
(in - Do not alter!).
$file: File path.
&$mime: MIME type (out).
'MimeMagicImproveFromExtension': Allows MW extensions to further improve the
MIME type detected by considering the file extension.
$mimeMagic: Instance of MimeAnalyzer.
$ext: File extension.
&$mime: MIME type (in/out).
'MimeMagicInit': Before processing the list mapping MIME types to media types
and the list mapping MIME types to file extensions.
As an extension author, you are encouraged to submit patches to MediaWiki's
core to add new MIME types to mime.types.
$mimeMagic: Instance of MimeAnalyzer.
Use $mimeMagic->addExtraInfo( $stringOfInfo );
for adding new MIME info to the list.
Use $mimeMagic->addExtraTypes( $stringOfTypes );
for adding new MIME types to the list.
'ModifyExportQuery': Modify the query used by the exporter.
$db: The database object to be queried.
&$tables: Tables in the query.
&$conds: Conditions in the query.
&$opts: Options for the query.
&$join_conds: Join conditions for the query.
'MovePageCheckPermissions': Specify whether the user is allowed to move the
page.
$oldTitle: Title object of the current (old) location
$newTitle: Title object of the new location
$user: User making the move
$reason: string of the reason provided by the user
$status: Status object to pass error messages to
'MovePageIsValidMove': Specify whether a page can be moved for technical
reasons.
$oldTitle: Title object of the current (old) location
$newTitle: Title object of the new location
$status: Status object to pass error messages to
'MultiContentSave': Before an article is saved.
$renderedRevision: RenderedRevision (object) representing the planned revision.
Provides access to: (1) ParserOutput of all slots,
(2) RevisionRecord, which contains
(2a) Title of the page that will be edited,
(2b) RevisionSlots - content of all slots, including inherited slots,
where content has already been modified by PreSaveTransform.
NOTE: because this revision is not yet saved, slots don't have content ID
or address, and revision itself doesn't have an ID.
$user: UserIdentity (object): author of this new revision.
$summary: CommentStoreComment (object): user-provided edit comment/summary
(not an autosummary: will be empty if the user hasn't provided a comment).
$flags: combination of EDIT_* flags, e.g. EDIT_MINOR.
$status: if the hook is aborted, error code can be placed into this Status.
'NamespaceIsMovable': Called when determining if it is possible to pages in a
namespace.
$index: Integer; the index of the namespace being checked.
&$result: Boolean; whether MediaWiki currently thinks that pages in this
namespace are movable. Hooks may change this value to override the return
value of NamespaceInfo::isMovable().
'NewDifferenceEngine': Called when a new DifferenceEngine object is made
$title: the diff page title (nullable)
&$oldId: the actual old Id to use in the diff
&$newId: the actual new Id to use in the diff (0 means current)
$old: the ?old= param value from the url
$new: the ?new= param value from the url
'NewPagesLineEnding': Called before a NewPages line is finished.
$page: the SpecialNewPages object
&$ret: the HTML line
$row: the database row for this page (the recentchanges record and a few extras
- see NewPagesPager::getQueryInfo)
&$classes: the classes to add to the surrounding <li>
&$attribs: associative array of other HTML attributes for the <li> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'NewRevisionFromEditComplete': Called when a revision was inserted due to an
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
edit, file upload, import or page move.
$wikiPage: the WikiPage edited
$rev: the new revision
$originalRevId: if the edit restores or repeats an earlier revision (such as a
rollback or a null revision), the ID of that earlier revision. False otherwise.
(Used to be called $baseID.)
$user: the editing user
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
&$tags: tags to apply to the edit and recent change. This is empty, and
replacement is ignored, in the case of import or page move.
'OldChangesListRecentChangesLine': Customize entire recent changes line, or
return false to omit the line from RecentChanges and Watchlist special pages.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$changeslist: The OldChangesList instance.
&$s: HTML of the form "<li>...</li>" containing one RC entry.
$rc: The RecentChange object.
&$classes: array of css classes for the <li> element.
&$attribs: associative array of other HTML attributes for the <li> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'OpenSearchUrls': Called when constructing the OpenSearch description XML. Hooks
can alter or append to the array of URLs for search & suggestion formats.
&$urls: array of associative arrays with Url element attributes
'OpportunisticLinksUpdate': Called by WikiPage::triggerOpportunisticLinksUpdate
when a page view triggers a re-rendering of the page. This may happen
particularly if the parser cache is split by user language, and no cached
rendering of the page exists in the user's language. The hook is called
before checking whether page_links_updated indicates that the links are up
to date. Returning false will cause triggerOpportunisticLinksUpdate() to abort
without triggering any updates.
$page: the Page that was rendered.
$title: the Title of the rendered page.
$parserOutput: ParserOutput resulting from rendering the page.
'OtherAutoblockLogLink': Get links to the autoblock log from extensions which
autoblocks users and/or IP addresses too.
&$otherBlockLink: An array with links to other autoblock logs
2009-12-30 08:51:25 +00:00
'OtherBlockLogLink': Get links to the block log from extensions which blocks
users and/or IP addresses too.
&$otherBlockLink: An array with links to other block logs
2009-12-30 08:51:25 +00:00
$ip: The requested IP address or username
'OutputPageAfterGetHeadLinksArray': Called in OutputPage#getHeadLinksArray right
before returning the result.
&$tags: array containing all <head> links generated so far. The array format is
"link name or number => 'link HTML'".
$out: the OutputPage object
'OutputPageBeforeHTML': A page has been processed by the parser and the
resulting HTML is about to be displayed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$out: the OutputPage (object) that corresponds to the page
&$text: the text that will be displayed, in HTML (string)
'OutputPageBodyAttributes': Called when OutputPage::headElement is creating the
body tag to allow for extensions to add attributes to the body of the page they
might need. Or to allow building extensions to add body classes that aren't of
high enough demand to be included in core.
$out: The OutputPage which called the hook, can be used to get the real title
$sk: The Skin that called OutputPage::headElement
&$bodyAttrs: An array of attributes for the body tag passed to Html::openElement
'OutputPageCheckLastModified': when checking if the page has been modified
since the last visit.
&$modifiedTimes: array of timestamps.
The following keys are set: page, user, epoch
$out: OutputPage object (since 1.28)
'OutputPageMakeCategoryLinks': Links are about to be generated for the page's
categories. Implementations should return false if they generate the category
links, so the default link generation is skipped.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$out: OutputPage instance (object)
$categories: associative array, keys are category names, values are category
types ("normal" or "hidden")
&$links: array, intended to hold the result. Must be an associative array with
category types as keys and arrays of HTML links as values.
'OutputPageParserOutput': after adding a parserOutput to $wgOut
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$out: OutputPage instance (object)
$parserOutput: parserOutput instance being added in $out
'PageContentInsertComplete': After a new article is created.
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$wikiPage: WikiPage created
[&]$user: User creating the article
$content: New content as a Content object
$summary: Edit summary/comment
$isMinor: Whether or not the edit was marked as minor
$isWatch: (No longer used)
$section: (No longer used)
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$flags: Flags passed to WikiPage::doEditContent()
$revision: New Revision of the article
'PageContentLanguage': Allows changing the language in which the content of a
page is written. Defaults to the wiki content language.
$title: Title object
&$pageLang: the page content language. Input can be anything (under control of
hook subscribers), but hooks should return Language objects. Language code
strings are deprecated.
$userLang: the user language (Language object)
'PageContentSave': DEPRECATED since 1.35! Use MultiContentSave instead.
Before an article is saved.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wikiPage: the WikiPage (object) being saved
[&]$user: the user (object) saving the article
[&]$content: the new article content, as a Content object
&$summary: CommentStoreComment object containing the edit comment. Can be replaced with a new one.
$isminor: Boolean flag specifying if the edit was marked as minor.
$iswatch: Previously a watch flag. Currently unused, always null.
$section: Previously the section number being edited. Currently unused, always null.
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$flags: All EDIT_… flags (including EDIT_MINOR) as an integer number. See WikiPage::doEditContent
documentation for flags' definition.
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$status: StatusValue object for the hook handlers resulting status. Either set $status->fatal() or
return false to abort the save action.
'PageContentSaveComplete': After an article has been updated.
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$wikiPage: WikiPage modified
[&]$user: User performing the modification
$content: New content, as a Content object
$summary: Edit summary/comment
$isMinor: Whether or not the edit was marked as minor
$isWatch: (No longer used)
$section: (No longer used)
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$flags: Flags passed to WikiPage::doEditContent()
$revision: New Revision of the article
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$status: Status object about to be returned by doEditContent(). Since
MediaWiki 1.32, replacing the Status object by assigning through the reference
has had no effect.
$originalRevId: if the edit restores or repeats an earlier revision (such as a
rollback or a null revision), the ID of that earlier revision. False otherwise.
(Used to be called $baseRevId.)
$undidRevId: the rev ID (or 0) this edit undid
'PageDeletionDataUpdates': Called when constructing a list of DeferrableUpdate to be
executed when a page is deleted.
$title: The Title of the page being deleted.
$revision: A RevisionRecord representing the page's current revision at the time of deletion.
&$updates: A list of DeferrableUpdate that can be manipulated by the hook handler.
'PageHistoryBeforeList': When a history page list is about to be constructed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$article: the article that the history is loading for
$context: RequestContext object
'PageHistoryLineEnding': Right before the end <li> is added to a history line.
$historyAction: the action object
&$row: the revision row for this line
&$s: the string representing this parsed line
&$classes: array containing the <li> element classes
&$attribs: associative array of other HTML attributes for the <li> element.
Currently only data attributes reserved to MediaWiki are allowed
(see Sanitizer::isReservedDataAttribute).
'PageHistoryPager::doBatchLookups': Called after the pager query was run, before
any output is generated, to allow batch lookups for prefetching information
needed for display. If the hook handler returns false, the regular behavior of
doBatchLookups() is skipped.
$pager: the PageHistoryPager
$result: a ResultWrapper representing the query result
'PageHistoryPager::getQueryInfo': when a history pager query parameter set is
constructed.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$pager: the pager
&$queryInfo: the query parameters
'PageRenderingHash': NOTE: Consider using ParserOptionsRegister instead.
Alter the parser cache option hash key. A parser extension
which depends on user options should install this hook and append its values to
the key.
&$confstr: reference to a hash key string which can be modified
$user: User (object) requesting the page
&$forOptions: array of options the hash is for
'PageViewUpdates': Allow database (or other) changes to be made after a
page view is seen by MediaWiki. Note this does not capture views made
via external caches such as Squid.
$wikipage: WikiPage (object) for the page being viewed.
$user: User (object) for the user who is viewing.
'ParserAfterParse': Called from Parser::parse() just after the call to
Parser::internalParse() returns.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: parser object
&$text: text being parsed
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$stripState: stripState used (object)
'ParserAfterStrip': Called at end of parsing time.
TODO: No more strip, deprecated ?
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: parser object
&$text: text being parsed
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$stripState: stripState used (object)
'ParserAfterTidy': Called after MWTidy::tidy() in Parser::parse()
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object being used
&$text: text that will be returned
'ParserBeforeInternalParse': Called at the beginning of Parser::internalParse().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
&$text: text to parse
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$stripState: StripState instance being used
'ParserBeforePreprocess': Called at the beginning of Parser::preprocess()
$parser: Parser object
&$text: text to parse
$stripState: StripState instance being used
'ParserBeforeStrip': Called at start of parsing time.
TODO: No more strip, deprecated ?
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: parser object
&$text: text being parsed
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$stripState: stripState used (object)
'ParserBeforeTidy': DEPRECATED since 1.35!
Called before tidy and custom tags replacements.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object being used
&$text: actual text
'ParserCacheSaveComplete': Called after a ParserOutput has been committed to
the parser cache.
$parserCache: ParserCache object $parserOutput was stored in
$parserOutput: ParserOutput object that was stored
$title: Title of the page that was parsed to generate $parserOutput
$popts: ParserOptions used for generating $parserOutput
$revId: ID of the revision that was parsed to create $parserOutput
'ParserClearState': Called at the end of Parser::clearState().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object being cleared
'ParserCloned': Called when the parser is cloned.
$parser: Newly-cloned Parser object
'ParserFetchTemplate': DEPRECATED since 1.35!
Called when the parser fetches a template
$parser: Parser Parser object or false
$title: Title object of the template to be fetched
$rev: Revision object of the template
&$text: Transclusion text of the template or false or null
&$deps: Array of template dependencies with 'title', 'page_id', 'rev_id' keys
'ParserFirstCallInit': Called when the parser initialises for the first time.
[&]$parser: Parser object being initialised
'ParserGetVariableValueSwitch': Called when the parser needs the value of a
custom magic word
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
&$variableCache: array to cache the value; when you return
$variableCache[$magicWordId] should be the same as $ret
[&]$magicWordId: index (string) of the magic word (hook should not mutate it!)
&$ret: value of the magic word (the hook should set it)
Reconcile differences between arguments in hooks.txt and at the call site 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
2020-03-03 22:50:34 +00:00
[&]$frame: PPFrame object to use for expanding any template variables
'ParserGetVariableValueTs': Use this to change the value of the time for the
{{LOCAL...}} magic word.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
&$time: actual time (timestamp)
'ParserGetVariableValueVarCache': DEPRECATED since 1.35! Use this to
change the value of the variable cache or return false to not use it.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$parser: Parser object
&$varCache: variable cache (array)
'ParserLimitReportFormat': Called for each row in the parser limit report that
needs formatting. If nothing handles this hook, the default is to use "$key" to
get the label, and "$key-value" or "$key-value-text"/"$key-value-html" to
format the value.
$key: Key for the limit report item (string)
&$value: Value of the limit report item
&$report: String onto which to append the data
$isHTML: If true, $report is an HTML table with two columns; if false, it's
text intended for display in a monospaced font.
$localize: If false, $report should be output in English.
'ParserLimitReportPrepare': Called at the end of Parser:parse() when the parser
will include comments about size of the text parsed. Hooks should use
$output->setLimitReportData() to populate data. Functions for this hook should
not use $wgLang; do that in ParserLimitReportFormat instead.
$parser: Parser object
$output: ParserOutput object
'ParserMakeImageParams': Called before the parser make an image link, use this
to modify the parameters of the image.
$title: title object representing the file
$file: file object that will be used to create the image
&$params: 2-D array of parameters
$parser: Parser object that called the hook
'ParserOptionsRegister': Register additional parser options. Note that if you
change the default value for an option, all existing parser cache entries will
be invalid. To avoid bugs, you'll need to handle that somehow (e.g. with the
RejectParserCacheValue hook) because MediaWiki won't do it for you.
&$defaults: Set the default value for your option here.
&$inCacheKey: To fragment the parser cache on your option, set a truthy value
here.
&$lazyLoad: To lazy-initialize your option, set it null in $defaults and set a
callable here. The callable is passed the ParserOptions object and the option
name.
'ParserOutputPostCacheTransform': Called from ParserOutput::getText() to do
post-cache transforms.
$parserOutput: The ParserOutput object.
&$text: The text being transformed, before core transformations are done.
&$options: The options array being used for the transformation.
'ParserPreSaveTransformComplete': DEPRECATED since 1.35!
Called from Parser::preSaveTransform() after
processing is complete, giving the extension a chance to further modify the
wikitext.
$parser: the calling Parser instance
&$text: The transformed text, which can be modified by the hook
'ParserSectionCreate': DEPRECATED since 1.35!
Called each time the parser creates a document section
from wikitext. Use this to apply per-section modifications to HTML (like
wrapping the section in a DIV). Caveat: DIVs are valid wikitext, and a DIV
can begin in one section and end in another. Make sure your code can handle
that case gracefully. See the EditSectionClearerLink extension for an example.
$parser: the calling Parser instance
$section: the section number, zero-based, but section 0 is usually empty
&$sectionContent: ref to the content of the section. modify this.
$showEditLinks: boolean describing whether this section has an edit link
'ParserTestGlobals': Allows to define globals for parser tests.
&$globals: Array with all the globals which should be set for parser tests.
The arrays keys serve as the globals names, its values are the globals values.
'ParserTestTables': Alter the list of tables to duplicate when parser tests are
run. Use when page save hooks require the presence of custom tables to ensure
that tests continue to run properly.
&$tables: array of table names
'ParserOutputStashForEdit': Called when an edit stash parse finishes, before the
output is cached.
$page: the WikiPage of the candidate edit
$content: the Content object of the candidate edit
$output: the ParserOutput result of the candidate edit
$summary: the change summary of the candidate edit
$user: the User considering the edit
'PasswordPoliciesForUser': Alter the effective password policy for a user.
$user: User object whose policy you are modifying
&$effectivePolicy: Array of policy statements that apply to this user
'PerformRetroactiveAutoblock': Called before a retroactive autoblock is applied
to a user.
$block: Block object (which is set to be autoblocking)
&$blockIds: Array of block IDs of the autoblock
2006-05-08 22:20:55 +00:00
'PersonalUrls': Alter the user-specific navigation links (e.g. "my page,
my talk page, my contributions" etc).
&$personal_urls: Array of link specifiers (see SkinTemplate.php)
&$title: Title object representing the current page
$skin: SkinTemplate object providing context (e.g. to check if the user is
logged in, etc.)
2006-05-08 22:20:55 +00:00
'PingLimiter': Allows extensions to override the results of User::pingLimiter().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: User performing the action
$action: Action being performed
&$result: Whether or not the action should be prevented
Change $result and return false to give a definitive answer, otherwise
the built-in rate limiting checks are used, if enabled.
$incrBy: Amount to increment counter by
'PlaceNewSection': Override placement of new sections. Return false and put the
merged text into $text to override the default behavior.
$wikipage: WikiPage object
$oldtext: the text of the article before editing
$subject: subject of the new section
&$text: text of the new section
'PostLoginRedirect': Modify the post login redirect behavior.
Occurs after signing up or logging in, allows for interception of redirect.
&$returnTo: The page name to return to, as a string
&$returnToQuery: array of url parameters, mapping parameter names to values
&$type: type of login redirect as string;
error: display a return to link ignoring $wgRedirectOnLogin
signup: display a return to link using $wgRedirectOnLogin if needed
success: display a return to link using $wgRedirectOnLogin if needed
successredirect: send an HTTP redirect using $wgRedirectOnLogin if needed
'PreferencesFormPreSave': Override preferences being saved
$formData: array of user submitted data
$form: HTMLForm object, also a ContextSource
$user: User object with preferences to be saved set
&$result: boolean indicating success
$oldUserOptions: array with user old options (before save)
'PreferencesGetLegend': Override the text used for the <legend> of a
preferences section.
$form: the HTMLForm object. This is a ContextSource as well
$key: the section name
&$legend: the legend text. Defaults to wfMessage( "prefs-$key" )->text() but may
be overridden
'PrefixSearchBackend': DEPRECATED since 1.27! Override
SearchEngine::completionSearchBackend instead.
Override the title prefix search used for OpenSearch and
AJAX search suggestions. Put results into &$results outparam and return false.
$ns: array of int namespace keys to search in
$search: search term (not guaranteed to be conveniently normalized)
$limit: maximum number of results to return
&$results: out param: array of page names (strings)
$offset: number of results to offset from the beginning
'PrefixSearchExtractNamespace': Called if core was not able to extract a
namespace from the search string so that extensions can attempt it.
&$namespaces: array of int namespace keys to search in (change this if you can
extract namespaces)
&$search: search term (replace this with term without the namespace if you can
extract one)
'PrefsEmailAudit': Called when user changes their email address.
$user: User (object) changing his email address
$oldaddr: old email address (string)
$newaddr: new email address (string)
'ProtectionForm::buildForm': Called after all protection type fieldsets are made
in the form.
$article: the title being (un)protected
&$output: a string of the form HTML so far
'ProtectionForm::save': Called when a protection form is submitted.
$article: the Page being (un)protected
&$errorMsg: an html message string of an error or an array of message name and
its parameters
$reasonstr: a string describing the reason page protection level is altered
'ProtectionForm::showLogExtract': Called after the protection log extract is
shown.
$article: the page the form is shown for
$out: OutputPage object
'RandomPageQuery': Lets you modify the query used by Special:Random to select
random pages.
&$tables: Database tables to be used in the query
&$conds: Conditions to be applied in the query
&$joinConds: Join conditions to be applied in the query
'RawPageViewBeforeOutput': Right before the text is blown out in action=raw.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$obj: RawAction object
&$text: The text that's going to be the output
'RecentChange_save': Called at the end of RecentChange::save().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$recentChange: RecentChange object
'RecentChangesPurgeRows': Called when old recentchanges rows are purged, after
deleting those rows but within the same transaction.
$rows: The deleted rows as an array of recentchanges row objects (with up to
$wgUpdateRowsPerQuery items).
'RedirectSpecialArticleRedirectParams': Lets you alter the set of parameter
names such as "oldid" that are preserved when using redirecting special pages
such as Special:MyPage and Special:MyTalk.
&$redirectParams: An array of parameters preserved by redirecting special pages.
'RejectParserCacheValue': Return false to reject an otherwise usable
cached value from the Parser cache. NOTE: CARELESS USE OF THIS HOOK CAN
HAVE CATASTROPHIC CONSEQUENCES FOR HIGH-TRAFFIC INSTALLATIONS. USE WITH
EXTREME CARE.
$parserOutput: ParserOutput value.
$wikiPage: WikiPage object.
$parserOptions: ParserOptions object.
'RequestContextCreateSkin': Called when RequestContext::getSkin creates a skin
instance. Can be used by an extension override what skin is used in certain
contexts.
$context: (IContextSource) The RequestContext the skin is being created for.
&$skin: A variable reference you may set a Skin instance or string key on to
override the skin that will be used for the context.
'RequestHasSameOriginSecurity': Called to determine if the request is somehow
flagged to lack same-origin security. Return false to indicate the lack. Note
if the "somehow" involves HTTP headers, you'll probably need to make sure
the header is varied on.
$request: The WebRequest object.
'ResetPasswordExpiration': Allow extensions to set a default password expiration
$user: The user having their password expiration reset
&$newExpire: The new expiration date
'ResourceLoaderForeignApiModules': Called from ResourceLoaderForeignApiModule.
Use this to add dependencies to 'mediawiki.ForeignApi' module when you wish
to override its behavior. See the module docs for more information.
&$dependencies: string[] List of modules that 'mediawiki.ForeignApi' should
depend on
$context: ResourceLoaderContext|null
'ResourceLoaderGetConfigVars': Called at the end of
ResourceLoaderStartUpModule::getConfigSettings(). Use this to export static
configuration variables to JavaScript. Things that depend on the current page
or request state must be added through MakeGlobalVariablesScript instead.
Skin is made available for skin specific config.
&$vars: [ variable name => value ]
$skin: Skin
$config: Config object (since 1.34)
'ResourceLoaderJqueryMsgModuleMagicWords': Called in
ResourceLoaderJqueryMsgModule to allow adding magic words for jQueryMsg.
The value should be a string, and they can depend only on the
ResourceLoaderContext.
$context: ResourceLoaderContext
&$magicWords: Associative array mapping all-caps magic word to a string value
'ResourceLoaderRegisterModules': Right before modules information is required,
such as when responding to a resource
loader request or generating HTML output.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$resourceLoader: ResourceLoader object
'ResourceLoaderTestModules': DEPRECATED since 1.33! Register ResourceLoader modules
that are only available when `$wgEnableJavaScriptTest` is true. Use this for test
suites and other test-only resources.
&$testModules: one array of modules per test framework. The modules array
follows the same format as `$wgResourceModules`. For example:
$testModules['qunit']['ext.Example.test'] = [
'localBasePath' => __DIR__ . '/tests/qunit',
'remoteExtPath' => 'Example/tests/qunit',
'script' => [ 'tests/qunit/foo.js' ],
'dependencies' => [ 'ext.Example.foo' ]
];
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$ResourceLoader: object
'RevisionDataUpdates': Called when constructing a list of DeferrableUpdate to be
executed to record secondary data about a revision.
$title: The Title of the page the revision belongs to
$renderedRevision: a RenderedRevision object representing the new revision and providing access
to the RevisionRecord as well as ParserOutput of that revision.
&$updates: A list of DeferrableUpdate that can be manipulated by the hook handler.
'RevisionRecordInserted': Called after a revision is inserted into the database.
$revisionRecord: the RevisionRecord that has just been inserted.
'RevisionInsertComplete': DEPRECATED since 1.31! Use RevisionRecordInserted hook
instead. Called after a revision is inserted into the database.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$revision: the Revision
$data: DEPRECATED! Always null!
$flags: DEPRECATED! Always null!
2008-04-15 15:38:08 +00:00
'RevisionUndeleted': After an article revision is restored.
$revisionRecord: the RevisionRecord that was restored
$oldPageID: the page ID of the revision when archived (may be null)
'RollbackComplete': After an article rollback is completed.
$wikiPage: the WikiPage that was edited
$user: UserIdentity for the user who did the rollback
$revision: RevisionRecord for the revision the page was reverted back to
$current: RevisionRecord for the reverted revision
'SearchableNamespaces': An option to modify which namespaces are searchable.
&$arr: Array of namespaces ($nsId => $name) which will be used.
'SearchAfterNoDirectMatch': If there was no match for the exact result. This
runs before lettercase variants are attempted, whereas 'SearchGetNearMatch'
runs after.
$term: Search term string
&$title: Outparam; set to $title object and return false for a match
'SearchGetNearMatch': An extra chance for exact-title-matches in "go" searches
if nothing was found.
$term: Search term string
&$title: Outparam; set to $title object and return false for a match
'SearchGetNearMatchBefore': Perform exact-title-matches in "go" searches before
the normal operations.
$allSearchTerms: Array of the search terms in all content languages
&$titleResult: Outparam; the value to return. A Title object or null.
'SearchGetNearMatchComplete': A chance to modify exact-title-matches in "go"
searches.
$term: Search term string
&$title: Current Title object that is being returned (null if none found).
'SearchResultInitFromTitle': Set the revision used when displaying a page in
search results.
$title: Current Title object being displayed in search results.
&$id: Revision ID (default is false, for latest)
'SearchIndexFields': Add fields to search index mapping.
&$fields: Array of fields, all implement SearchIndexField
$engine: SearchEngine instance for which mapping is being built.
'SearchDataForIndex': Add data to search document. Allows to add any data to
the field map used to index the document.
&$fields: Array of name => value pairs for fields
$handler: ContentHandler for the content being indexed
$page: WikiPage that is being indexed
$output: ParserOutput that is produced from the page
$engine: SearchEngine for which the indexing is intended
'SearchResultsAugment': Allows extension to add its code to the list of search
result augmentors.
&$setAugmentors: List of whole-set augmentor objects, must implement
ResultSetAugmentor.
&$rowAugmentors: List of per-row augmentor objects, must implement
ResultAugmentor.
Note that lists should be in the format name => object and the names in both
lists should be distinct.
'SecondaryDataUpdates': DEPRECATED since 1.32! Use RevisionDataUpdates or override
ContentHandler::getSecondaryDataUpdates instead.
Allows modification of the list of DataUpdates to perform when page content is modified.
$title: Title of the page that is being edited.
$oldContent: Content object representing the page's content before the edit.
$recursive: bool indicating whether DataUpdates should trigger recursive
updates (relevant mostly for LinksUpdate).
$parserOutput: ParserOutput representing the rendered version of the page
after the edit.
&$updates: a list of DataUpdate objects, to be modified or replaced by
the hook handler.
'SecuritySensitiveOperationStatus': Affect the return value from
MediaWiki\Auth\AuthManager::securitySensitiveOperationStatus().
&$status: (string) The status to be returned. One of the AuthManager::SEC_*
constants. SEC_REAUTH will be automatically changed to SEC_FAIL if
authentication isn't possible for the current session type.
$operation: (string) The operation being checked.
$session: (MediaWiki\Session\Session) The current session. The
currently-authenticated user may be retrieved as $session->getUser().
$timeSinceAuth: (int) The time since last authentication. PHP_INT_MAX if
the time of last auth is unknown, or -1 if authentication is not possible.
'SelfLinkBegin': Called before a link to the current article is displayed to
allow the display of the link to be customized.
$nt: the Title object
&$html: html to display for the link
&$trail: optional text to display before $html
&$prefix: optional text to display after $html
&$ret: the value to return if your hook returns false
'SendWatchlistEmailNotification': Return true to send watchlist email
notification
$targetUser: the user whom to send watchlist email notification
$title: the page title
$enotif: EmailNotification object
'SessionCheckInfo': Validate a MediaWiki\Session\SessionInfo as it's being
loaded from storage. Return false to prevent it from being used.
&$reason: String rejection reason to be logged
$info: MediaWiki\Session\SessionInfo being validated
$request: WebRequest being loaded from
$metadata: Array|false Metadata array for the MediaWiki\Session\Session
$data: Array|false Data array for the MediaWiki\Session\Session
'SessionMetadata': Add metadata to a session being saved.
$backend: MediaWiki\Session\SessionBackend being saved.
&$metadata: Array Metadata to be stored. Add new keys here.
$requests: Array of WebRequests potentially being saved to. Generally 0-1 real
request and 0+ FauxRequests.
2008-12-11 11:50:45 +00:00
'SetupAfterCache': Called in Setup.php, after cache objects are set
'ShortPagesQuery': Allow extensions to modify the query used by
Special:ShortPages.
&$tables: tables to join in the query
&$conds: conditions for the query
&$joinConds: join conditions for the query
&$options: options for the query
'ShowMissingArticle': Called when generating the output for a non-existent page.
$article: The article object corresponding to the page
'ShowSearchHit': Customize display of search hit.
$searchPage: The SpecialSearch instance.
$result: The SearchResult to show
$terms: Search terms, for highlighting (unreliable as search engine dependent).
&$link: HTML of link to the matching page. May be modified.
&$redirect: HTML of redirect info. May be modified.
&$section: HTML of matching section. May be modified.
&$extract: HTML of content extract. May be modified.
&$score: HTML of score. May be modified.
&$size: HTML of page size. May be modified.
&$date: HTML of of page modification date. May be modified.
&$related: HTML of additional info for the matching page. May be modified.
&$html: May be set to the full HTML that should be used to represent the search
hit. Must include the <li> ... </li> tags. Will only be used if the hook
function returned false.
'ShowSearchHitTitle': Customise display of search hit title/link.
&$title: Title to link to
&$titleSnippet: Label for the link representing the search result. Typically the
article title.
$result: The SearchResult object
$terms: array of search terms extracted by SearchDatabase search engines
(may not be populated by other search engines).
$specialSearch: The SpecialSearch object
&$query: Array of query string parameters for the link representing the search
result.
&$attributes: Array of title link attributes, can be modified by extension.
'SidebarBeforeOutput': Allows to edit sidebar just before it is output by skins.
Warning: This hook is run on each display. You should consider to use
'SkinBuildSidebar' that is aggressively cached.
$skin: Skin object
&$bar: Sidebar content
Modify $bar to add or modify sidebar portlets.
'SiteNoticeAfter': After the sitenotice/anonnotice is composed.
&$siteNotice: HTML sitenotice. Alter the contents of $siteNotice to add to/alter
the sitenotice/anonnotice.
$skin: Skin object
'SiteNoticeBefore': Before the sitenotice/anonnotice is composed. Return true to
allow the normal method of notice selection/rendering to work, or change the
value of $siteNotice and return false to alter it.
&$siteNotice: HTML returned as the sitenotice
$skin: Skin object
'SkinAfterBottomScripts': At the end of Skin::bottomScripts().
$skin: Skin object
&$text: bottomScripts Text. Append to $text to add additional text/scripts after
the stock bottom scripts.
'SkinAfterContent': Allows extensions to add text after the page content and
article metadata. This hook should work in all skins. Set the &$data variable to
the text you're going to add.
&$data: (string) Text to be printed out directly (without parsing)
$skin: Skin object
'SkinBuildSidebar': At the end of Skin::buildSidebar().
$skin: Skin object
&$bar: Sidebar contents
Modify $bar to add or modify sidebar portlets.
'SkinCopyrightFooter': Allow for site and per-namespace customization of
copyright notice.
$title: displayed page title
$type: 'normal' or 'history' for old/diff views
&$msg: overridable message; usually 'copyright' or 'history_copyright'. This
message must be in HTML format, not wikitext!
&$link: overridable HTML link to be passed into the message as $1
'ResourceLoaderSiteModulePages': Modify list of pages for a given skin
$skin: string of the current skin key
&$pages: array of pages and their types.
'ResourceLoaderSiteStylesModulePages': Modify list of pages for a given skin
$skin: string of the current skin key
&$pages: array of pages and their types.
'SkinEditSectionLinks': Modify the section edit links
$skin: Skin object rendering the UI
$title: Title object for the title being linked to (may not be the same as
the page title, if the section is included from a template)
$section: The designation of the section being pointed to, to be included in
the link, like "&section=$section"
$tooltip: The default tooltip. Escape before using.
By default, this is wrapped in the 'editsectionhint' message.
&$result: Array containing all link detail arrays. Each link detail array should
contain the following keys:
- targetTitle - Target Title object
- text - String for the text
- attribs - Array of attributes
- query - Array of query parameters to add to the URL
$lang: The language code to use for the link in the wfMessage function
'SkinGetPoweredBy': TODO
&$text: additional 'powered by' icons in HTML. Note: Modern skin does not use
the MediaWiki icon but plain text instead.
$skin: Skin object
'SkinPreloadExistence': Supply titles that should be added to link existence
cache before the page is rendered.
&$titles: Array of Title objects
$skin: Skin object
'SkinSubPageSubtitle': At the beginning of Skin::subPageSubtitle().
If false is returned $subpages will be used instead of the HTML
subPageSubtitle() generates.
If true is returned, $subpages will be ignored and the rest of
subPageSubtitle() will run.
&$subpages: Subpage links HTML
$skin: Skin object
$out: OutputPage object
'SkinTemplateBuildNavUrlsNav_urlsAfterPermalink': After creating the "permanent
link" tab.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: SkinTemplate object
&$nav_urls: array of tabs
&$revid: The revision id of the permanent link
&$revid2: The revision id of the permanent link, second time
'SkinTemplateGetLanguageLink': After building the data for a language link from
which the actual html is constructed.
&$languageLink: array containing data about the link. The following keys can be
modified: href, text, title, class, lang, hreflang. Each of them is a string.
$languageLinkTitle: Title object belonging to the external language link.
$title: Title object of the page the link belongs to.
$outputPage: The OutputPage object the links are built from.
'SkinTemplateNavigation': Called on content pages after the tabs have been
added, but before variants have been added.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: SkinTemplate object
&$links: Structured navigation links. This is used to alter the navigation for
skins which use buildNavigationUrls such as Vector.
'SkinTemplateNavigation::SpecialPage': Called on special pages after the special
tab is added but before variants have been added.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: SkinTemplate object
&$links: Structured navigation links. This is used to alter the navigation for
skins which use buildNavigationUrls such as Vector.
'SkinTemplateNavigation::Universal': Called on both content and special pages
after variants have been added.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: SkinTemplate object
&$links: Structured navigation links. This is used to alter the navigation for
skins which use buildNavigationUrls such as Vector.
'SkinTemplateOutputPageBeforeExec': Before SkinTemplate::outputPage() starts
page output.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: SkinTemplate object
[&]$tpl: QuickTemplate engine object
'SkinTemplatePreventOtherActiveTabs': Use this to prevent showing active tabs.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: SkinTemplate object
&$res: set to true to prevent active tabs
'SkinTemplateTabAction': Override SkinTemplate::tabAction().
You can either create your own array, or alter the parameters for
the normal one.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sktemplate: The SkinTemplate instance.
$title: Title instance for the page.
$message: Visible label of tab.
$selected: Whether this is a selected tab.
$checkEdit: Whether or not the action=edit query should be added if appropriate.
&$classes: Array of CSS classes to apply.
&$query: Query string to add to link.
&$text: Link text.
&$result: Complete assoc. array if you want to return true.
'SkinTemplateToolboxEnd': Called by SkinTemplate skins after toolbox links have
been rendered (useful for adding more).
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$sk: The QuickTemplate based skin template running the hook.
2011-10-09 19:42:45 +00:00
$dummy: Called when SkinTemplateToolboxEnd is used from a BaseTemplate skin,
extensions that add support for BaseTemplateToolbox should watch for this
dummy parameter with "$dummy=false" in their code and return without echoing
any HTML to avoid creating duplicate toolbox items.
'SoftwareInfo': Called by Special:Version for returning information about the
software.
&$software: The array of software in format 'name' => 'version'. See
SpecialVersion::softwareInformation().
'SpecialBlockModifyFormFields': Add more fields to Special:Block
$sp: SpecialPage object, for context
&$fields: Current HTMLForm fields
'SpecialContributionsBeforeMainOutput': Before the form on Special:Contributions
$id: User id number, only provided for backwards-compatibility
$user: User object representing user contributions are being fetched for
$sp: SpecialPage instance, providing context
'SpecialContributions::formatRow::flags': Called before rendering a
Special:Contributions row.
$context: IContextSource object
$row: Revision information from the database
&$flags: List of flags on this row
'SpecialContributions::getForm::filters': Called with a list of filters to render
on Special:Contributions.
$sp: SpecialContributions object, for context
&$filters: List of filter object definitions (compatible with OOUI form)
'SpecialListusersDefaultQuery': Called right before the end of
UsersPager::getDefaultQuery().
$pager: The UsersPager instance
&$query: The query array to be returned
'SpecialListusersFormatRow': Called right before the end of
UsersPager::formatRow().
&$item: HTML to be returned. Will be wrapped in an <li> after the hook finishes
$row: Database row object
'SpecialListusersHeader': Called after adding the submit button in
UsersPager::getPageHeader().
$pager: The UsersPager instance
&$out: The header HTML
'SpecialListusersHeaderForm': Called before adding the submit button in
UsersPager::getPageHeader().
$pager: The UsersPager instance
&$out: The header HTML
'SpecialListusersQueryInfo': Called right before the end of.
UsersPager::getQueryInfo()
$pager: The UsersPager instance
&$query: The query array to be returned
'SpecialLogAddLogSearchRelations': Add log relations to the current log
$type: String of the log type
$request: WebRequest object for getting the value provided by the current user
&$qc: Array for query conditions to add
'SpecialMovepageAfterMove': Called after moving a page.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$movePage: MovePageForm object
[&]$oldTitle: old title (object)
[&]$newTitle: new title (object)
'SpecialMuteModifyFormFields': Add more fields to Special:Mute
$sp: SpecialPage object, for context
&$fields: Current HTMLForm fields descriptors
'SpecialMuteSubmit': DEPRECATED since 1.34! Used only for instrumentation on SpecialMute
$data: Array containing information about submitted options on SpecialMute form
'SpecialNewpagesConditions': Called when building sql query for
Special:NewPages.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$special: NewPagesPager object (subclass of ReverseChronologicalPager)
$opts: FormOptions object containing special page options
&$conds: array of WHERE conditionals for query
&$tables: array of tables to be queried
&$fields: array of columns to select
&$join_conds: join conditions for the tables
'SpecialNewPagesFilters': Called after building form options at NewPages.
$special: the special page object
&$filters: associative array of filter definitions. The keys are the HTML
name/URL parameters. Each key maps to an associative array with a 'msg'
(message key) and a 'default' value.
'SpecialPage_initList': Called when setting up SpecialPageFactory::$list, use
this hook to remove a core special page or conditionally register special pages.
&$list: list (array) of core special pages
'SpecialPageAfterExecute': Called after SpecialPage::execute.
$special: the SpecialPage object
$subPage: the subpage string or null if no subpage was specified
'SpecialPageBeforeExecute': Called before SpecialPage::execute.
Return false to prevent execution.
$special: the SpecialPage object
$subPage: the subpage string or null if no subpage was specified
'SpecialPageBeforeFormDisplay': Before executing the HTMLForm object.
$name: name of the special page
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$form: HTMLForm object
'SpecialPasswordResetOnSubmit': When executing a form submission on
Special:PasswordReset.
&$users: array of User objects.
$data: array of data submitted by the user
&$error: string, error code (message key) used to describe to error (out
parameter). The hook needs to return false when setting this, otherwise it
will have no effect.
'SpecialRandomGetRandomTitle': Called during the execution of Special:Random,
use this to change some selection criteria or substitute a different title.
&$randstr: The random number from wfRandom()
&$isRedir: Boolean, whether to select a redirect or non-redirect
&$namespaces: An array of namespace indexes to get the title from
&$extra: An array of extra SQL statements
&$title: If the hook returns false, a Title object to use instead of the
result from the normal query
'SpecialRecentChangesPanel': Called when building form options in
SpecialRecentChanges.
&$extraOpts: array of added items, to which can be added
$opts: FormOptions for this request
2013-06-14 16:59:59 +00:00
'SpecialResetTokensTokens': Called when building token list for
SpecialResetTokens.
&$tokens: array of token information arrays in the format of
[
'preference' => '<preference-name>',
'label-message' => '<message-key>',
]
2013-06-14 16:59:59 +00:00
'SpecialSearchCreateLink': Called when making the message to create a page or
go to the existing page.
$t: title object searched for
&$params: an array of the default message name and page title (as parameter)
'SpecialSearchGoResult': If a hook returns false the 'go' feature will be
canceled and a normal search will be performed. Returning true without setting
$url does a standard redirect to $title. Setting $url redirects to the
specified URL.
$term: The string the user searched for
$title: The title the 'go' feature has decided to forward the user to
&$url: Initially null, hook subscribers can set this to specify the final url to
redirect to
'SpecialSearchNogomatch': Called when the 'Go' feature is triggered (generally
from autocomplete search other than the main bar on Special:Search) and the
target doesn't exist. Full text search results are generated after this hook is
called.
2010-12-12 18:17:33 +00:00
&$title: title object generated from the text entered by the user
'SpecialSearchPowerBox': The equivalent of SpecialSearchProfileForm for
the advanced form, a.k.a. power search box.
&$showSections: an array to add values with more options to
$term: the search term (not a title object)
&$opts: an array of hidden options (containing 'redirs' and 'profile')
'SpecialSearchProfileForm': Allows modification of search profile forms.
$search: special page object
&$form: String: form html
$profile: String: current search profile
$term: String: search term
$opts: Array: key => value of hidden options for inclusion in custom forms
'SpecialSearchProfiles': Allows modification of search profiles.
&$profiles: profiles, which can be modified.
'SpecialSearchResults': Called before search result display
$term: string of search term
&$titleMatches: empty or ISearchResultSet object
&$textMatches: empty or ISearchResultSet object
'SpecialSearchResultsPrepend': Called immediately before returning HTML
on the search results page. Useful for including an external search
provider. To disable the output of MediaWiki search output, return
false.
$specialSearch: SpecialSearch object ($this)
$output: $wgOut
$term: Search term specified by the user
'SpecialSearchResultsAppend': Called immediately before returning HTML
on the search results page. Useful for including a feedback link.
$specialSearch: SpecialSearch object ($this)
$output: $wgOut
$term: Search term specified by the user
'SpecialSearchSetupEngine': Allows passing custom data to search engine.
$search: SpecialSearch special page object
$profile: String: current search profile
$engine: the search engine
'SpecialStatsAddExtra': Add extra statistic at the end of Special:Statistics.
&$extraStats: Array to save the new stats
$extraStats['<name of statistic>'] => <value>;
<value> can be an array with the keys "name" and "number":
"name" is the HTML to be displayed in the name column
"number" is the number to be displayed.
or, <value> can be the number to be displayed and <name> is the
message key to use in the name column,
$context: IContextSource object
'SpecialTrackingCategories::preprocess': Called after LinkBatch on
Special:TrackingCategories
$specialPage: The SpecialTrackingCategories object
$trackingCategories: Array of data from Special:TrackingCategories with msg and
cats
'SpecialTrackingCategories::generateCatLink': Called for each cat link on
Special:TrackingCategories
$specialPage: The SpecialTrackingCategories object
$catTitle: The Title object of the linked category
&$html: The Result html
'SpecialUploadComplete': Called after successfully uploading a file from
Special:Upload.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$form: The SpecialUpload object
2009-07-19 20:03:13 +00:00
'SpecialVersionVersionUrl': Called when building the URL for Special:Version.
$version: Current MediaWiki version
&$versionUrl: Raw url to link to (eg: release notes)
'SpecialWatchlistGetNonRevisionTypes': Called when building sql query for
SpecialWatchlist. Allows extensions to register custom values they have
inserted to rc_type so they can be returned as part of the watchlist.
&$nonRevisionTypes: array of values in the rc_type field of recentchanges table
'TestCanonicalRedirect': Called when about to force a redirect to a canonical
URL for a title when we have no other parameters on the URL. Gives a chance for
extensions that alter page view behavior radically to abort that redirect or
handle it manually.
$request: WebRequest
$title: Title of the currently found title obj
$output: OutputPage object
'ThumbnailBeforeProduceHTML': Called before an image HTML is about to be
rendered (by ThumbnailImage:toHtml method).
$thumbnail: the ThumbnailImage object
&$attribs: image attribute array
&$linkAttribs: image link attribute array
'TitleArrayFromResult': Called when creating an TitleArray object from a
database result.
&$titleArray: set this to an object to override the default object returned
$res: database result used to create the object
'TitleExists': Called when determining whether a page exists at a given title.
$title: The title being tested.
&$exists: Whether the title exists.
'TitleGetEditNotices': Allows extensions to add edit notices
$title: The Title object for the page the edit notices are for
$oldid: Revision ID that the edit notices are for (or 0 for latest)
&$notices: Array of notices. Keys are i18n message keys, values are
parseAsBlock()ed messages.
'TitleGetRestrictionTypes': Allows extensions to modify the types of protection
that can be applied.
$title: The title in question.
&$types: The types of protection available.
'TitleIsAlwaysKnown': Called when determining if a page exists. Allows
overriding default behavior for determining if a page exists. If $isKnown is
kept as null, regular checks happen. If it's a boolean, this value is returned
by the isKnown method.
2012-02-09 14:10:59 +00:00
$title: Title object that is being checked
&$isKnown: Boolean|null; whether MediaWiki currently thinks this page is known
2012-02-09 14:10:59 +00:00
'TitleIsMovable': Called when determining if it is possible to move a page. Note
that this hook is not called for interwiki pages or pages in immovable
namespaces: for these, isMovable() always returns false.
$title: Title object that is being checked
&$result: Boolean; whether MediaWiki currently thinks this page is movable.
Hooks may change this value to override the return value of
Title::isMovable().
'TitleMove': Before moving an article (title).
$old: old title
$nt: new title
$user: user who does the move
$reason: string of the reason provided by the user
&$status: Status object. To abort the move, add a fatal error to this object
(i.e. call $status->fatal()).
'TitleMoveStarting': Before moving an article (title), but just after the atomic
DB section starts.
$old: old title
$nt: new title
$user: user who does the move
'TitleMoveComplete': After moving an article (title), post-commit.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$old: old title
[&]$nt: new title
[&]$user: user who did the move
$pageid: database ID of the page that's been moved
$redirid: database ID of the created redirect
$reason: reason for the move
$revision: the Revision created by the move
'TitleMoveCompleting': After moving an article (title), pre-commit.
$old: old title
$nt: new title
$user: user who did the move
$pageid: database ID of the page that's been moved
$redirid: database ID of the created redirect
$reason: reason for the move
$revision: the Revision created by the move
'TitleQuickPermissions': Called from Title::checkQuickPermissions to add to
or override the quick permissions check.
$title: The Title object being accessed
$user: The User performing the action
$action: Action being performed
&$errors: Array of errors
$doExpensiveQueries: Whether to do expensive DB queries
$short: Whether to return immediately on first error
'TitleReadWhitelist': Called at the end of read permissions checks, just before
adding the default error message if nothing allows the user to read the page. If
a handler wants a title to *not* be whitelisted, it should also return false.
$title: Title object being checked against
$user: Current user object
&$whitelisted: Boolean value of whether this title is whitelisted
'HtmlCacheUpdaterAppendUrls': Declare extra URLs to purge from HTTP caches.
Use $mode to decide whether to gather all related URLs or only those affected by
a re-render of the same content. For example, after a direct revision to the
content the history page will need to be purged. However when re-rendering after
a cascading change from a template, only URLs that render content need purging.
The $mode will be either HtmlCacheUpdater::PURGE_URLS_LINKSUPDATE_ONLY or 0.
$title: Title object for the page being purged.
$mode: Integer.
&$append: Append URLs relating to $title.
'HtmlCacheUpdaterVaryUrls': Add variants of URLs to purge from HTTP caches.
Extensions that provide site-wide variants of all URLs, such as by serving from
an alternate domain or path, can use this hook to append alternative URLs for
each url in $canonical.
$urls: Canonical URLs.
&$append: Append alternative URLs for $urls.
'TitleSquidURLs': Called to determine which URLs to purge from HTTP caches.
$title: Title object to purge
&$urls: An array of URLs to purge from the caches, to be manipulated.
'UnblockUser': Before an IP address or user is unblocked.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$block: The Block object about to be saved
[&]$user: The user performing the unblock (not the one being unblocked)
&$reason: If the hook is aborted, the error message to be returned in an array
'UnblockUserComplete': After an IP address or user has been unblocked.
$block: The Block object that was saved
$user: The user who performed the unblock (not the one being unblocked)
'UndeleteForm::showHistory': Called in UndeleteForm::showHistory, after a
PageArchive object has been created but before any further processing is done.
&$archive: PageArchive object
$title: Title object of the page that we're viewing
'UndeleteForm::showRevision': Called in UndeleteForm::showRevision, after a
PageArchive object has been created but before any further processing is done.
&$archive: PageArchive object
$title: Title object of the page that we're viewing
'UndeleteForm::undelete': Called in UndeleteForm::undelete, after checking that
the site is not in read-only mode, that the Title object is not null and after
a PageArchive object has been constructed but before performing any further
processing.
&$archive: PageArchive object
$title: Title object of the page that we're about to undelete
'UndeletePageToolLinks': Add one or more links to edit page subtitle when a page
has been previously deleted.
$context: IContextSource (object)
$linkRenderer: LinkRenderer instance
&$links: Array of HTML strings
'UndeleteShowRevision': DEPRECATED since 1.35!
Called when showing a revision in Special:Undelete.
$title: title object related to the revision
$rev: revision (object) that will be viewed
'UnitTestsAfterDatabaseSetup': Called right after MediaWiki's test
infrastructure has finished creating/duplicating core tables for unit tests.
$database: Database in question
$prefix: Table prefix to be used in unit tests
'UnitTestsBeforeDatabaseTeardown': Called right before MediaWiki tears down its
database infrastructure used for unit tests.
'UnitTestsList': Called when building a list of paths containing PHPUnit tests.
Since 1.24: Paths pointing to a directory will be recursively scanned for
test case files matching the suffix "Test.php".
&$paths: list of test cases and directories to search.
'UnwatchArticle': Before a watch is removed from an article.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user watching
[&]$page: WikiPage object to be removed
&$status: Status object to be returned if the hook returns false
'UnwatchArticleComplete': After a watch is removed from an article.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user that watched
[&]$page: WikiPage object that was watched
2007-08-28 21:53:50 +00:00
'UpdateUserMailerFormattedPageStatus': Before notification email gets sent.
&$formattedPageStatus: list of valid page states
'UploadComplete': Upon completion of a file upload.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$uploadBase: UploadBase (or subclass) object. File can be accessed by
$uploadBase->getLocalFile().
'UploadCreateFromRequest': When UploadBase::createFromRequest has been called.
$type: (string) the requested upload type
&$className: the class name of the Upload instance to be created
'UploadForm:BeforeProcessing': At the beginning of processUpload(). Lets you
poke at member variables like $mUploadDescription before the file is saved.
Do not use this hook to break upload processing.
This will return the user to a blank form with no error message;
use UploadVerifyUpload or UploadVerifyFile instead.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$upload: SpecialUpload object
'UploadForm:getInitialPageText': After the initial page text for file uploads
is generated, to allow it to be altered.
&$pageText: the page text
$msg: array of header messages
$config: Config object
'UploadForm:initial': Before the upload form is generated. You might set the
member-variables $uploadFormTextTop and $uploadFormTextAfterSummary to inject
text (HTML) either before or after the editform.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$upload: SpecialUpload object
'UploadFormInitDescriptor': After the descriptor for the upload form as been
assembled.
&$descriptor: (array) the HTMLForm descriptor
'UploadFormSourceDescriptors': after the standard source inputs have been
added to the descriptor
&$descriptor: (array) the HTMLForm descriptor
&$radio: Boolean, if source type should be shown as radio button
$selectedSourceType: The selected source type
Introduce UploadStashFile hook, improve API handling of stash errors UploadBase: * Introduce a new method, tryStashFile(), as a replacement for the now-soft-deprecated stashFile(). The method runs the new hook and returns a Status object, with an error (if the hook returned an error) or a value (if it didn't). * Introduce a new hook, UploadStashFile, allowing extensions to prevent a file from being stashed. Note that code in extensions which has not been updated for MediaWiki 1.28 may still call stashFile() directly, and therefore not call this hook. For important checks (not just for UI), extension authors should use UploadVerifyFile or UploadVerifyUpload hooks. * Extract common code of tryStashFile() and stashFile() to a new protected method doStashFile(). SpecialUpload: * Use tryStashFile() when stashing a file after a warning or "recoverable error" was encountered. ApiUpload: * Refactor stashing code so that error handling only happens in one place, not four different ones. Use Status objects rather than exception throwing/catching for control flow. * Simplify the error messages slightly (error codes are unchanged). Produce better ones by always using handleStashException(). 'stashfailed' is now always at root (not nested inside 'warnings'), behaving the same as 'filekey' does on success. * Use tryStashFile() when stashing. Handle errors so as to allow custom API results passed via ApiMessage to be preserved. Some API result changes for different requests are shown below. api.php?action=upload&format=json&filename=good.png&file=...&stash=1 Before: { "error": { "code": "stashfilestorage", "info": "Could not store upload in the stash: Stashing temporary file failed: UploadStashFileException Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\".", "*": "See http://localhost:3080/w/api.php for API usage" } } After: { "error": { "code": "stashfilestorage", "info": "Could not store upload in the stash: Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\".", "*": "See http://localhost:3080/w/api.php for API usage" } } api.php?action=upload&format=json&filename=[bad].png&file=... Before: { "upload": { "result": "Warning", "warnings": { "badfilename": "-bad-.png", "stashfailed": "Stashing temporary file failed: UploadStashFileException Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\"." } } } After: { "upload": { "result": "Warning", "stashfailed": "Could not store upload in the stash: Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\"." "warnings": { "badfilename": "-bad-.png", } } } Bug: T140521 Change-Id: I2f574b355cd33b2e9fa7ff8e1793503b257cce65
2016-08-03 00:13:01 +00:00
'UploadStashFile': Before a file is stashed (uploaded to stash).
Note that code which has not been updated for MediaWiki 1.28 may not call this
hook. If your extension absolutely, positively must prevent some files from
being uploaded, use UploadVerifyFile or UploadVerifyUpload.
$upload: (object) An instance of UploadBase, with all info about the upload
$user: (object) An instance of User, the user uploading this file
$props: (array|null) File properties, as returned by
MWFileProps::getPropsFromPath(). Note this is not always guaranteed to be set,
e.g. in test scenarios. Call MWFileProps::getPropsFromPath() yourself in case
you need the information.
&$error: output: If the file stashing should be prevented, set this to the
reason in the form of [ messagename, param1, param2, ... ] or a
MessageSpecifier instance (you might want to use ApiMessage to provide machine
-readable details for the API).
Introduce UploadStashFile hook, improve API handling of stash errors UploadBase: * Introduce a new method, tryStashFile(), as a replacement for the now-soft-deprecated stashFile(). The method runs the new hook and returns a Status object, with an error (if the hook returned an error) or a value (if it didn't). * Introduce a new hook, UploadStashFile, allowing extensions to prevent a file from being stashed. Note that code in extensions which has not been updated for MediaWiki 1.28 may still call stashFile() directly, and therefore not call this hook. For important checks (not just for UI), extension authors should use UploadVerifyFile or UploadVerifyUpload hooks. * Extract common code of tryStashFile() and stashFile() to a new protected method doStashFile(). SpecialUpload: * Use tryStashFile() when stashing a file after a warning or "recoverable error" was encountered. ApiUpload: * Refactor stashing code so that error handling only happens in one place, not four different ones. Use Status objects rather than exception throwing/catching for control flow. * Simplify the error messages slightly (error codes are unchanged). Produce better ones by always using handleStashException(). 'stashfailed' is now always at root (not nested inside 'warnings'), behaving the same as 'filekey' does on success. * Use tryStashFile() when stashing. Handle errors so as to allow custom API results passed via ApiMessage to be preserved. Some API result changes for different requests are shown below. api.php?action=upload&format=json&filename=good.png&file=...&stash=1 Before: { "error": { "code": "stashfilestorage", "info": "Could not store upload in the stash: Stashing temporary file failed: UploadStashFileException Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\".", "*": "See http://localhost:3080/w/api.php for API usage" } } After: { "error": { "code": "stashfilestorage", "info": "Could not store upload in the stash: Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\".", "*": "See http://localhost:3080/w/api.php for API usage" } } api.php?action=upload&format=json&filename=[bad].png&file=... Before: { "upload": { "result": "Warning", "warnings": { "badfilename": "-bad-.png", "stashfailed": "Stashing temporary file failed: UploadStashFileException Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\"." } } } After: { "upload": { "result": "Warning", "stashfailed": "Could not store upload in the stash: Error storing file in '/tmp/phpB32SRT': Could not create directory \"mwstore://local-backend/local-temp/3/3a\"." "warnings": { "badfilename": "-bad-.png", } } } Bug: T140521 Change-Id: I2f574b355cd33b2e9fa7ff8e1793503b257cce65
2016-08-03 00:13:01 +00:00
'UploadVerifyFile': extra file verification, based on MIME type, etc.
$upload: (object) an instance of UploadBase, with all info about the upload
$mime: (string) The uploaded file's MIME type, as detected by MediaWiki.
Handlers will typically only apply for specific MIME types.
&$error: (object) output: true if the file is valid. Otherwise, set this to the
reason in the form of [ messagename, param1, param2, ... ] or a
MessageSpecifier instance (you might want to use ApiMessage to provide machine
-readable details for the API).
'UploadVerifyUpload': Upload verification, based on both file properties like
MIME type (same as UploadVerifyFile) and the information entered by the user
(upload comment, file page contents etc.).
$upload: (object) An instance of UploadBase, with all info about the upload
$user: (object) An instance of User, the user uploading this file
$props: (array|null) File properties, as returned by
MWFileProps::getPropsFromPath(). Note this is not always guaranteed to be set,
e.g. in test scenarios. Call MWFileProps::getPropsFromPath() yourself in case
you need the information.
$comment: (string) Upload log comment (also used as edit summary)
$pageText: (string) File description page text (only used for new uploads)
&$error: output: If the file upload should be prevented, set this to the reason
in the form of [ messagename, param1, param2, ... ] or a MessageSpecifier
instance (you might want to use ApiMessage to provide machine-readable details
for the API).
'UserIsBot': when determining whether a user is a bot account
$user: the user
&$isBot: whether this is user a bot or not (boolean)
'User::mailPasswordInternal': before creation and mailing of a user's new
temporary password
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: the user who sent the message out
[&]$ip: IP of the user who sent the message out
[&]$u: the account whose new password will be set
User group memberships that expire This patch adds an ug_expiry column to the user_groups table, a timestamp giving a date when the user group expires. A new UserGroupMembership class, based on the Block class, manages entries in this table. When the expiry date passes, the row in user_groups is ignored, and will eventually be purged from the DB when UserGroupMembership::insert is next called. Old, expired user group memberships are not kept; instead, the log entries are available to find the history of these memberships, similar to the way it has always worked for blocks and protections. Anyone getting user group info through the User object will get correct information. However, code that reads the user_groups table directly will now need to skip over rows with ug_expiry < wfTimestampNow(). See UsersPager for an example of how to do this. NULL is used to represent infinite (no) expiry, rather than a string 'infinity' or similar (except in the API). This allows existing user group assignments and log entries, which are all infinite in duration, to be treated the same as new, infinite-length memberships, without special casing everything. The whole thing is behind the temporary feature flag $wgDisableUserGroupExpiry, in accordance with the WMF schema change policy. The opportunity has been taken to refactor some static user-group-related functions out of User into UserGroupMembership, and also to add a primary key (ug_user, ug_group) to the user_groups table. There are a few breaking changes: - UserRightsProxy-like objects are now required to have a getGroupMemberships() function. - $user->mGroups (on a User object) is no longer present. - Some protected functions in UsersPager are altered or removed. - The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted extension) has a change of parameter. Bug: T12493 Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8 Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
2017-01-12 06:07:56 +00:00
'UserAddGroup': Called when adding a group or changing a group's expiry; return
false to override stock group addition.
$user: the user object that is to have a group added
User group memberships that expire This patch adds an ug_expiry column to the user_groups table, a timestamp giving a date when the user group expires. A new UserGroupMembership class, based on the Block class, manages entries in this table. When the expiry date passes, the row in user_groups is ignored, and will eventually be purged from the DB when UserGroupMembership::insert is next called. Old, expired user group memberships are not kept; instead, the log entries are available to find the history of these memberships, similar to the way it has always worked for blocks and protections. Anyone getting user group info through the User object will get correct information. However, code that reads the user_groups table directly will now need to skip over rows with ug_expiry < wfTimestampNow(). See UsersPager for an example of how to do this. NULL is used to represent infinite (no) expiry, rather than a string 'infinity' or similar (except in the API). This allows existing user group assignments and log entries, which are all infinite in duration, to be treated the same as new, infinite-length memberships, without special casing everything. The whole thing is behind the temporary feature flag $wgDisableUserGroupExpiry, in accordance with the WMF schema change policy. The opportunity has been taken to refactor some static user-group-related functions out of User into UserGroupMembership, and also to add a primary key (ug_user, ug_group) to the user_groups table. There are a few breaking changes: - UserRightsProxy-like objects are now required to have a getGroupMemberships() function. - $user->mGroups (on a User object) is no longer present. - Some protected functions in UsersPager are altered or removed. - The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted extension) has a change of parameter. Bug: T12493 Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8 Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
2017-01-12 06:07:56 +00:00
&$group: the group to add; can be modified
&$expiry: the expiry time in TS_MW format, or null if the group is not to
expire; can be modified
'UserArrayFromResult': Called when creating an UserArray object from a database
result.
&$userArray: set this to an object to override the default object returned
$res: database result used to create the object
'userCan': To interrupt/advise the "user can do X to Y article" check. If you
want to display an error message, try getUserPermissionsErrors.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$title: Title object being checked against
[&]$user: Current user object
$action: Action being checked
&$result: Pointer to result returned if hook returns false. If null is returned,
userCan checks are continued by internal code.
'UserCanSendEmail': To override User::canSendEmail() permission check.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: User (object) whose permission is being checked
2008-01-29 00:31:26 +00:00
&$canSend: bool set on input, can override on output
'UserClearNewTalkNotification': Called when clearing the "You have new
messages!" message, return false to not delete it.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: User (object) that will clear the message
Correctly update wl_notificationtimestamp when viewing old revisions == Prelude == wl_notificationtimestamp controls sending the user e-mail notifications about changes to pages, as well as showing the "updated since last visit" markers on history pages, recent changes and watchlist. == The bug == Previously, on every view of a page, the notification timestamp was cleared, regardless of whether the user as actually viewing the latest revision. When viewing a diff, however, the timestamp was cleared only if one of the revisions being compared was the latest one of its page. The same behavior applied to talk page message indicators (which are actually stored sepately to cater to anonymous users). This was inconsistent and surprising when one was attempting to, say, go through the 50 new posts to a discussion page in a peacemeal fashion. == The fix == If the revision being viewed is the latest (or can't be determined), the timestamp is cleared as previously, as this is necessary to reenable e-mail notifications for given user and page. If the revision isn't the latest, the timestamp is updated to revision's timestamp plus one second. This uses up to two simple (selectField) indexed queries per page view, only fired when we do not already know we're looking at the latest version. Talk page indicator is updated to point at the next revision after the one being viewed, or cleared if viewing the latest revision. The UserClearNewTalkNotification hook gained $oldid as the second argument (a backwards-compatible change). In Skin, we no longer ignore the indicator being present if we're viewing the talk page, as it might still be valid. == The bonus == Comments and formatting was updated in a few places, including tables.sql and Wiki.php. The following functions gained a second, optional $oldid parameter (holy indirection, Batman!): * WikiPage#doViewUpdates() * User#clearNotification() * WatchedItem#resetNotificationTimestamp() DifferenceEngine gained a public method mapDiffPrevNext() used to parse the ids from URL parameters like oldid=12345&diff=prev, factored out of loadRevisionIds(). A bug where the NewDifferenceEngine hook would not be called in some cases, dating back to its introduction in r45518, was fixed in the process. Bug: 41759 Change-Id: I4144ba1987b8d7a7e8b24f4f067eedac2ae44459
2013-09-16 10:31:40 +00:00
$oldid: ID of the talk page revision being viewed (0 means the most recent one)
'UserEffectiveGroups': Called in User::getEffectiveGroups().
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: User to get groups for
&$groups: Current effective groups
'UserGetAllRights': After calculating a list of all available rights.
&$rights: Array of rights, which may be added to.
'UserGetDefaultOptions': After fetching the core default, this hook is run right
before returning the options to the caller. Warning: This hook is called for
every call to User::getDefaultOptions(), which means it's potentially called
dozens or hundreds of times. You may want to cache the results of non-trivial
operations in your hook function for this reason.
&$defaultOptions: Array of preference keys and their default values.
'UserGetEmail': Called when getting an user email address.
2008-04-15 15:37:02 +00:00
$user: User object
&$email: email, change this to override local email
'UserGetEmailAuthenticationTimestamp': Called when getting the timestamp of
email authentication.
2008-04-15 15:37:02 +00:00
$user: User object
&$timestamp: timestamp, change this to override local email authentication
timestamp
2008-04-15 15:37:02 +00:00
'UserGetLanguageObject': Called when getting user's interface language object.
$user: User object
&$code: Language code that will be used to create the object
$context: IContextSource object
'UserGetReservedNames': Allows to modify $wgReservedUsernames at run time.
&$reservedUsernames: $wgReservedUsernames
2008-08-07 16:12:25 +00:00
'UserGetRights': Called in User::getRights().
2008-04-15 15:37:02 +00:00
$user: User to get rights for
&$rights: Current rights
'UserGetRightsRemove': Called in User::getRights(). This hook override
the UserGetRights hook. It can be used to remove rights from user
and ensure that will not be reinserted by the other hook callbacks
therefore this hook should not be used to add any rights, use UserGetRights instead.
$user: User to get rights for
&$rights: Current rights
'UserGroupsChanged': Called after user groups are changed.
$user: User whose groups changed
$added: Groups added
$removed: Groups removed
$performer: User who performed the change, false if via autopromotion
$reason: The reason, if any, given by the user performing the change,
false if via autopromotion.
$oldUGMs: An associative array (group name => UserGroupMembership object) of
the user's group memberships before the change.
$newUGMs: An associative array (group name => UserGroupMembership object) of
the user's current group memberships.
'UserIsBlockedFrom': Check if a user is blocked from a specific page (for
specific block exemptions if a user is already blocked).
2009-10-07 14:30:12 +00:00
$user: User in question
$title: Title of the page in question
&$blocked: Out-param, whether or not the user is blocked from that page.
&$allowUsertalk: If the user is blocked, whether or not the block allows users
to edit their own user talk pages.
2009-10-07 14:30:12 +00:00
2009-01-29 19:48:56 +00:00
'UserIsBlockedGlobally': Check if user is blocked on all wikis.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: User object
2009-01-29 19:48:56 +00:00
$ip: User's IP address
&$blocked: Whether the user is blocked, to be modified by the hook
&$block: The Block object, to be modified by the hook
2009-01-29 19:48:56 +00:00
'UserIsEveryoneAllowed': Check if all users are allowed some user right; return
false if a UserGetRights hook might remove the named right.
$right: The user right being checked
'UserIsLocked': Check if the user is locked. See User::isLocked().
$user: User in question.
&$locked: Set true if the user should be locked.
'UserLoadAfterLoadFromSession': Called to authenticate users on external or
environmental means; occurs after session is loaded.
$user: user object being loaded
'UserLoadDefaults': Called when loading a default user.
$user: user object
$name: user name
'UserLoadFromDatabase': Called when loading a user from the database.
$user: user object
&$s: database query object
'UserLoadOptions': When user options/preferences are being loaded from the
database.
$user: User object
&$options: Options, can be modified.
'UserLoggedIn': Called after a user is logged in
$user: User object for the logged-in user
'UserLoginComplete': Show custom content after a user has logged in via the Web
interface. For functionality that needs to run after any login (API or web) use
UserLoggedIn.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: the user object that was created on login
&$inject_html: Any HTML to inject after the "logged in" message.
$direct: (bool) The hook is called directly after a successful login. This will
only happen once per login. A UserLoginComplete call with direct=false can
happen when the user visits the login page while already logged in.
'UserLogout': Before a user logs out.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: the user object that is about to be logged out
'UserLogoutComplete': After a user has logged out.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: the user object _after_ logout (won't have name, ID, etc.)
&$inject_html: Any HTML to inject after the "logged out" message.
$oldName: name of the user before logout (string)
'UserMailerChangeReturnPath': Called to generate a VERP return address
when UserMailer sends an email, with a bounce handling extension.
$to: Array of MailAddress objects for the recipients
&$returnPath: The return address string
'UserMailerSplitTo': Called in UserMailer::send() to give extensions a chance
to split up an email with multiple the To: field into separate emails.
&$to: array of MailAddress objects; unset the ones which should be mailed
separately
'UserMailerTransformContent': Called in UserMailer::send() to change email
contents. Extensions can block sending the email by returning false and setting
$error.
$to: array of MailAdresses of the targets
$from: MailAddress of the sender
&$body: email body, either a string (for plaintext emails) or an array with
'text' and 'html' keys
&$error: should be set to an error message string
'UserMailerTransformMessage': Called in UserMailer::send() to change email after
it has gone through the MIME transform. Extensions can block sending the email
by returning false and setting $error.
$to: array of MailAdresses of the targets
$from: MailAddress of the sender
&$subject: email subject (not MIME encoded)
&$headers: email headers (except To: and Subject:) as an array of header
name => value pairs
&$body: email body (in MIME format) as a string
&$error: should be set to an error message string
'UserRemoveGroup': Called when removing a group; return false to override stock
group removal.
$user: the user object that is to have a group removed
&$group: the group to be removed, can be modified
'UserRequiresHTTPS': Called to determine whether a user needs
to be switched to HTTPS.
$user: User in question.
&$https: Boolean whether $user should be switched to HTTPS.
'UserResetAllOptions': Called in User::resetOptions() when user preferences
have been requested to be reset. This hook can be used to exclude certain
options from being reset even when the user has requested all prefs to be reset,
because certain options might be stored in the user_properties database table
despite not being visible and editable via Special:Preferences.
$user: the User (object) whose preferences are being reset
&$newOptions: array of new (site default) preferences
$options: array of the user's old preferences
$resetKinds: array containing the kinds of preferences to reset
'UserRetrieveNewTalks': Called when retrieving "You have new messages!"
message(s).
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user retrieving new talks messages
&$talks: array of new talks page(s)
'UserSaveOptions': Called just before saving user preferences. Hook handlers can
either add or manipulate options, or reset one back to it's default to block
changing it. Hook handlers are also allowed to abort the process by returning
false, e.g. to save to a global profile instead. Compare to the UserSaveSettings
hook, which is called after the preferences have been saved.
$user: The User for which the options are going to be saved
&$options: The users options as an associative array, modifiable
'UserSaveSettings': Called directly after user preferences (user_properties in
the database) have been saved. Compare to the UserSaveOptions hook, which is
called before.
$user: The User for which the options have been saved
'UserSendConfirmationMail': Called just before a confirmation email is sent to
a user. Hook handlers can modify the email that will be sent.
$user: The User for which the confirmation email is going to be sent
&$mail: Associative array describing the email, with the following keys:
- subject: Subject line of the email
- body: Email body. Can be a string, or an array with keys 'text' and 'html'
- from: User object, or null meaning $wgPasswordSender will be used
- replyTo: MailAddress object or null
$info: Associative array with additional information:
- type: 'created' if the user's account was just created; 'set' if the user
set an email address when they previously didn't have one; 'changed' if
the user had an email address and changed it
- ip: The IP address from which the user set/changed their email address
- confirmURL: URL the user should visit to confirm their email
- invalidateURL: URL the user should visit to invalidate confirmURL
- expiration: time and date when confirmURL expires
'UserSetCookies': DEPRECATED since 1.27! If you're trying to replace core
session cookie handling, you want to create a subclass of
MediaWiki\Session\CookieSessionProvider instead. Otherwise, you can no longer
count on user data being saved to cookies versus some other mechanism.
Called when setting user cookies.
$user: User object
&$session: session array, will be added to the session
&$cookies: cookies array mapping cookie name to its value
'UserSetEmail': Called when changing user email address.
2008-04-15 15:37:02 +00:00
$user: User object
&$email: new email, change this to override new email address
'UserSetEmailAuthenticationTimestamp': Called when setting the timestamp of
email authentication.
2008-04-15 15:37:02 +00:00
$user: User object
&$timestamp: new timestamp, change this to override local email
authentication timestamp
2008-04-15 15:37:02 +00:00
'UserToolLinksEdit': Called when generating a list of user tool links, e.g.
"Foobar (Talk | Contribs | Block)".
$userId: User id of the current user
$userText: User name of the current user
2011-11-23 00:56:45 +00:00
&$items: Array of user tool links as HTML fragments
'UsersPagerDoBatchLookups': Called in UsersPager::doBatchLookups() to give
extensions providing user group data from an alternate source a chance to add
their data into the cache array so that things like global user groups are
displayed correctly in Special:ListUsers.
$dbr: Read-only database handle
$userIds: Array of user IDs whose groups we should look up
User group memberships that expire This patch adds an ug_expiry column to the user_groups table, a timestamp giving a date when the user group expires. A new UserGroupMembership class, based on the Block class, manages entries in this table. When the expiry date passes, the row in user_groups is ignored, and will eventually be purged from the DB when UserGroupMembership::insert is next called. Old, expired user group memberships are not kept; instead, the log entries are available to find the history of these memberships, similar to the way it has always worked for blocks and protections. Anyone getting user group info through the User object will get correct information. However, code that reads the user_groups table directly will now need to skip over rows with ug_expiry < wfTimestampNow(). See UsersPager for an example of how to do this. NULL is used to represent infinite (no) expiry, rather than a string 'infinity' or similar (except in the API). This allows existing user group assignments and log entries, which are all infinite in duration, to be treated the same as new, infinite-length memberships, without special casing everything. The whole thing is behind the temporary feature flag $wgDisableUserGroupExpiry, in accordance with the WMF schema change policy. The opportunity has been taken to refactor some static user-group-related functions out of User into UserGroupMembership, and also to add a primary key (ug_user, ug_group) to the user_groups table. There are a few breaking changes: - UserRightsProxy-like objects are now required to have a getGroupMemberships() function. - $user->mGroups (on a User object) is no longer present. - Some protected functions in UsersPager are altered or removed. - The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted extension) has a change of parameter. Bug: T12493 Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8 Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
2017-01-12 06:07:56 +00:00
&$cache: Array of user ID -> (array of internal group name (e.g. 'sysop') ->
UserGroupMembership object)
&$groups: Array of group name -> bool true mappings for members of a given user
group
'ValidateExtendedMetadataCache': Called to validate the cached metadata in
FormatMetadata::getExtendedMeta (return false means cache will be
invalidated and GetExtendedMetadata hook called again).
$timestamp: The timestamp metadata was generated
$file: The file the metadata is for
'WantedPages::getQueryInfo': Called in WantedPagesPage::getQueryInfo(), can be
used to alter the SQL query which gets the list of wanted pages.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$wantedPages: WantedPagesPage object
&$query: query array, see QueryPage::getQueryInfo() for format documentation
'WatchArticle': Before a watch is added to an article.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user that will watch
[&]$page: WikiPage object to be watched
&$status: Status object to be returned if the hook returns false
$expiry: Optional expiry timestamp in any format acceptable to wfTimestamp()
'WatchArticleComplete': After a watch is added to an article.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$user: user that watched
[&]$page: WikiPage object watched
2007-07-02 23:22:39 +00:00
'WatchedItemQueryServiceExtensions': Create a WatchedItemQueryServiceExtension.
&$extensions: Add WatchedItemQueryServiceExtension objects to this array
$watchedItemQueryService: Service object
'WatchlistEditorBeforeFormRender': Before building the Special:EditWatchlist
form, used to manipulate the list of pages or preload data based on that list.
&$watchlistInfo: array of watchlisted pages in
[namespaceId => ['title1' => 1, 'title2' => 1]] format
'WatchlistEditorBuildRemoveLine': when building remove lines in
Special:Watchlist/edit.
&$tools: array of extra links
$title: Title object
$redirect: whether the page is a redirect
$skin: Skin object
&$link: HTML link to title
'WebRequestPathInfoRouter': While building the PathRouter to parse the
REQUEST_URI.
$router: The PathRouter instance
'WebResponseSetCookie': when setting a cookie in WebResponse::setcookie().
Return false to prevent setting of the cookie.
&$name: Cookie name passed to WebResponse::setcookie()
&$value: Cookie value passed to WebResponse::setcookie()
&$expire: Cookie expiration, as for PHP's setcookie()
&$options: Options passed to WebResponse::setcookie()
'wfShellWikiCmd': Called when generating a shell-escaped command line string to
run a MediaWiki cli script.
&$script: MediaWiki cli script path
&$parameters: Array of arguments and options to the script
&$options: Associative array of options, may contain the 'php' and 'wrapper'
keys
'wgQueryPages': Called when initialising list of QueryPage subclasses, use this
to add new query pages to be updated with maintenance/updateSpecialPages.php.
&$qp: The list of QueryPages
'WhatLinksHereProps': Allows annotations to be added to WhatLinksHere
$row: The DB row of the entry.
$title: The Title of the page where the link comes FROM
$target: The Title of the page where the link goes TO
&$props: Array of HTML strings to display after the title.
'WikiExporter::dumpStableQuery': Get the SELECT query for "stable" revisions
dumps. One, and only one hook should set this, and return false.
&$tables: Database tables to use in the SELECT query
&$opts: Options to use for the query
&$join: Join conditions
'WikiPageDeletionUpdates': DEPRECATED since 1.32! Use PageDeletionDataUpdates or
override ContentHandler::getDeletionDataUpdates instead.
Manipulates the list of DeferrableUpdates to be applied when a page is deleted.
$page: the WikiPage
$content: the Content to generate updates for, or null in case the page revision
could not be loaded. The delete will succeed despite this.
&$updates: the array of objects that implement DeferrableUpdate. Hook function
may want to add to it.
'WikiPageFactory': Override WikiPage class used for a title
$title: Title of the page
&$page: Variable to set the created WikiPage to.
'XmlDumpWriterOpenPage': Called at the end of XmlDumpWriter::openPage, to allow
extra metadata to be added.
$obj: The XmlDumpWriter object.
&$out: The output string.
$row: The database row for the page.
$title: The title of the page.
'XmlDumpWriterWriteRevision': Called at the end of a revision in an XML dump, to
add extra metadata.
Annotate hook parameters that are references for legacy reasons. 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
2020-02-28 05:40:45 +00:00
[&]$obj: The XmlDumpWriter object.
&$out: The text being output.
$row: The database row for the revision being dumped. DEPRECATED, use $rev instead.
$text: The revision text to be dumped. DEPRECATED, use $rev instead.
$rev: The RevisionRecord that is being dumped to XML
More hooks might be available but undocumented, you can execute
"php maintenance/findHooks.php" to find hidden ones.