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
Example usage:
$wgHooks['MessageCache::get'][] = function( &$key ) {
static $keys = null;
if ( $keys === null ) {
global $wgExtensionMessagesFiles;
require( $wgExtensionMessagesFiles['OverrideMessages'] );
$keys = array_flip( array_keys( $messages['en'] ) );
}
if ( isset( $keys["myprefix-$key"] ) ) {
$key = "myprefix-$key";
}
return true;
}
Pros:
* Easy way to override standard core and extension messages without
any changes to them
* Messages can be stored in a standard i18n file
* Messages can be translated easily with Translate
* Messages can be shared accross multiple wikis easily
* Takes advantage of the normal message cache behavior unlike the
MessagePreLoad hook
* Missing translations fallback to the override, not to the
uncustomized standard translation
* Do not need to handle conflicting message keys at translatewiki.net
if adopted by WMF
Cons:
* This method is called often, so there will be small performance
impact if no hooks are registered. Impact can be big if the
implementation of hook subscriber is inefficient.
This can help with bugs like 36149. It doesn't remove the manual work
needed to detect those messages and adding them to the i18n file.
I have been using this patch in a wiki farm for months.
Change-Id: Ib39937a440e71ae7292cf992ab37a569189741e4
Added SkinTemplateGetLanguageLink hook to allow changing the html of
language links. This is needed by the Wikibase extension to display badges
of sitelinks.
Bug: 60717
Change-Id: I223bf7a7bb0d13942a81b1766acbee62e080348d
Most of the time people wouldn't need this - this hook is mostly
used to inject a custom Article subclass for a specific
namespace to do fancy things, but lets give users the most
flexibility.
Asked for by leaves on irc.
Change-Id: I3386ff4abe0e5b3eb783604ae222b7703428db44
With this fix and relevant fix for ConfirmEdit in, an API account creation
attempt that fails the captcha check will return a much cleaner error such as:
{
'error': {
'code': 'captcha-createaccount-fail',
'info': 'Incorrect or missing CAPTCHA.'
}
}
Abort hooks that use the old interface and send a text message will now
be reported with the generic 'createaccount-hook-abort' message code, with the
string passed back intact.
Previously, the returned result would list the contents of the message
_as_ the error code, making it hard for a client to determine the error.
'AbortNewAccount' hook clients can add a '&$status=null' function paramater
on their signature, and along with the back-compat message parameter
you can set something like:
$msg = wfMessage( 'captcha-createaccount-fail' )->text(); // back-compat
$status = Status::newFatal( 'captcha-createaccount-fail' ); // new
This is done for ConfirmEdit in If9cc08e
Bug: 60008
Change-Id: I6ae34c00d1051d34363b6d654424be17dcb1ea30
New hooks:
* AddNewAccountApiForm
* AddNewAccountApiResult
These hooks are used in ConfirmEdit here: Id628def
Sample API client: https://github.com/brion/api-createaccount
Bug: 46072
Change-Id: If5b7dab80ac85dbfa0f7a54a445356783df5e914
The SpecialWatchlistQuery hook now gets a FormOptions object as the last
parameter instead of an array (which is not bad as bad as it sounds, since
the class implements ArrayAccess).
Change-Id: Iec4aab870b6e9aa98d2b118010e78e25b1dbe437
To generate a user-dependent cache key it makes sense to pass
a reference to the user object, since $wgUser is deprecated.
Change-Id: I32a1df52912292230852c31d69968eeb312a4a97
The current id number is useless for IP addresses, so it now
passes a proper User object.
For context, the SpecialPage instance is also provided.
Change-Id: Ie196611d504b3969bcdfb5c589716af2f3c54e14
When importing, we need to check that the kind of content we are about to
import is actually allowed in the specified location on the local wiki.
This change does two things:
* Introduce the ContentModelCanBeUsedOn hook which provides control over
which kind of content can be used where.
* Introduce a check against ContentHandler::canBeUsedOn in the importer,
along with an appropriate error message.
Change-Id: Ia2ff0b0474f4727c9ebbba3c0a2a111495055f61
$wgExtensionFunctions is called before the RequestContext is really
available (i.e. getTitle() is null, accessing the User object may fail
because other extensions' UserLoadFromSession hooks don't expect to be
called that early, etc). The index.php code path has BeforeInitialize to
take action after RequestContext is available but before much else
happens, but the API doesn't (yet) have anything similar.
Bug: 58380
Change-Id: I0a167faaa4166da381194c53373d82e038848924
