Hooks with dynamically generated names cannot be documented in the normal
manner, and indeed this set, added in r86482 / 10d93c34cb, was not.
In contrast, every other hook in core has a name that is a fixed string
and thus is easy to grep for, create a manual page title for, and so on.
Conceptually, each hook's name should correspond to one or more locations
at which code can be inserted.
So I changed the code to use hook name "SpecialPageBeforeFormDisplay"
for all FormSpecialPages and added the special page name as a parameter,
which is consistent with existing hook "ActionBeforeFormDisplay".
From extensions in Gerrit, the only use I found was in StopForumSpam,
which is updated to use the new hook in Id474915a. So I chose to break
backward compatibility instead of using a hack to hide the old hooks
from maintenance/findHooks.php.
After three years, the script again reports, "Looks good!"
Change-Id: I7ea6521b47fb034bc367a1d06d477a7654035a5f
This hook is poorly thought out. The only extension that uses it
can't possibly think it works how they're expecting.
Change-Id: I853a01afc8e922f22e949321a2f2343d264632a6
* Correct typo in docs/hooks.txt.
* Add a few directories.
Left unfixed is "Undocumented: Special{$this->getName()}BeforeFormDisplay",
which will be addressed separately.
Change-Id: I4fda8960642c23500bd20e0b89c1d1327456313b
Allows for modifying returnTo url, url parameters, and the redirect
type.
New return to condition 'signup' if redirecting after signup
Treated same as 'success', though now explicitly marking as such
Part of making GettingStarted not dependent on CentralAuth
Bug: 65619
Change-Id: I219353d9825918e22d4772611a38d72c4e674e10
For ZERO, we need to be able to avoid forceHTTPS from taking place in
case user logged in while on wifi, and later switched to
zero.wikipedia.org for the carrier who doesn't support HTTPS.
In that case, the extension will need to be able to cancel redirect
and force regular HTTP handling.
Open Question: should this code log off user in case hook returns false?
Bug 65567
Change-Id: If04c83066c5d47b3c04ad7674e3c4e95a4cd464b
Called before a link to the current article is displayed to allow the display
of the link to be customized.
Bug: 63592
Change-Id: I343e1b1b08ec841d22a1b22bcb8af43bb65a5a50
All other footer content is rendered in the user language and the
copyright notice on the edit page is also in the user language.
See EditPage::getCopyrightWarning().
We already do this on WMF wikis through the WikimediaMessages
extension (which sets $forContent to false). The same behaviour has
been requested for 3rd party wikis as well.
Bug: 49116
Change-Id: I1dddfa7771c7063ec319fa441c2e400a374abc92
This should explain the conventions of the MediaWiki project.
Wikimedia is a prominent user of MediaWiki, but not the only one.
Other MediaWiki installations do not share all of Wikimedia's
values and mission. However, it is possible to express common values
that should guide this work in core.
Thus, I retained some of the existing text, as well as adding one other
point, accessibility (which we have discussed but was not mentioned
here).
Change-Id: Iafc8641c9b89138b3e4b7f6e274395279ddad43c
Allows to modify sidebar abstract representation just before its output
Required by change Ib4014253016db1c3d6b624be9ebbdaf452115145
Change-Id: I170e7253825c8dab5cad38e6b0ba59f28572efbf
This hooks allows extensions to override the normal model-specific
rendering of page content. A typical use would be to provide syntax
highlighting for pages that contain scripts. In that sense,
ContentGetParserOutput is a generalization of the old ShowRawCssJs
hook.
This, together with I76412f9d, is a (hopefully) fixed version of the
reverted Ibfb2cbefea44.
Change-Id: I979e2438689648ba4c959d8083197ef14ce524e8
In bug 63240, Roan calls it a 'misfeature', which I think is exactly right. It
has been used as a lazy workaround for having to think about load-order,
dependency management, and race conditions.
Bug: 63240
Change-Id: Ic48ad39c6d3d166d6bb8f60dfdd5f95aa7ed16a6
Nothing is listed on mw.org as using these and nothing in Git uses
them either. Less hooks is a good thing, we've still got 11 here :(
Change-Id: I2dd1dbb269820b192f8d9e9a496a161f4ef851bf
EditPage::showReadOnlyForm:initial which is analogous to
EditPage::showEditForm:initial
Bug: 45258
Change-Id: I6885d617e18562acf0331e8db5790b53b489dbc2
The static method 'Linker::makeMediaLinkFile' produced a HTML string
without usage of MediaWiki 'Html' class. It also lacked a hook to allow
modifications of the output HTML.
I altered the implementation and added a hook that provides a signature
and behaviour similar to the existing 'LinkerMakeExternalLink' and
'LinkBegin'/'LinkEnd' hooks. It provides all available context information
and allows modification of single attributes or the output HTML as a
whole. I have updated the 'docs/hooks.txt' file to provide proper
documentation.
Change-Id: I6d7769298a4ca6cbbf807fcebb91fb0d2222f8d8
Old hooks (called by SpecialWatchlist, SpecialRecentChanges and
SpecialRecentChangesLinked) have been deprecated, but I'm not planning
to remove them anytime soon. (They have lots of usages in extensions
as of this writing.)
The new hooks (and their deprecated friends) are:
* ChangesListSpecialPageFilters:
* Replaces: SpecialRecentChangesFilters and SpecialWatchlistFilters
* The signature for this one is exactly the same as signatures for
the other two. We might want to pass something else than $this
here…
* ChangesListSpecialPageQuery
* Replaces: SpecialRecentChangesQuery and SpecialWatchlistQuery
* These hooks have wildly different signatures. The new one is a
superset of the old ones, in a more reasonable order, with the
addition of the name of the special page we're doing right now.
Change-Id: I9cceda5d2dcfc53c852c5682c466b48ad8f31202
An extension hooking into recent changes may need to load additional
data that did not fit into the recentchanges table. This hook gives
extensions an opportunity to see the full result prior to rendering
and batch load where approprite rather than loading piecemeal during
the render process.
This is implemented as an optional method called by the ChangesList
consumer, since the ChangesList never sees the full result set. Hook
implementers must be able to work regardless of the hook being called,
they just have the oportunity to be more efficient when it is called.
Change-Id: If74ae600ffba949364dd381dd3d466cbbaa27286
The Flow extension has need to change the url output by
the IRC formatter. As a temporary fix this allows flow
to conditionally replace the url until RC can be adjusted
to inteligently generate URL's in a cross-extension way.
Change-Id: Ie951e52833a578fecd9423c2e6d3cc10816d7fef
Allows extensions to move away from using (or abusing) the
SkinTemplateOutputPageBeforeExec hook to add things in places
such as after the list of language links.
Also explicitly check that $template->data['language_urls'] is not false.
Extensions can set it to an empty array to have the language links
header be displayed.
Bug: 57094
Change-Id: I099fb2ff48e02a2e3564a484aea906263e40bb53
Add functionality to expire users' passwords:
* Adds column to the user table to keep a password expiration
* Adds $wgPasswordExpirationDays, which will force users to reset
their passwords after a set number of days. By default, this set
to false, so passwords never expire.
* Adds a default grace period of 7 days, where if the user's password
is expired, they can still login, but are encouraged to reset their
password.
* Adds hook 'LoginPasswordResetMessage' to update reset message, in
case an extension wants to vary the message on a particular reset
event.
* Adds hook 'ResetPasswordExpiration' to allow extensions to change
the expiration date when the user resets their password. E.g., if
an extension wants to vary the expiration based on the user's group.
If the user is in the grace period, they get a password reset form
added to the login successful page. If an extension prevents showing
the login successful page (like CentralAuth), it should be updated to
show a password change form during the grace period. After the grace
period, the user will not be able to login without changing their
password.
Also prevents a successful reset if the user is "changing" their
password to their existing password.
No passwords will expire by default. Sites will have to call
User->expirePassword() from their own maintenance script to trigger a
password reset for a user.
Bug: 54997
Change-Id: I92a9fc63b409b182b1d7b48781d73fc7216f8061
As with the ArticleDeletionComplete hook, include the reason for
moving the title (article) when firing the TitleMoveComplete hook.
See I98703f99a47d5786b7a567df954ba09f6d8862ff for a supporting use
case.
Change-Id: I875446dddacff7e5a52a0b6e577e6a46a9ae2e6f
