This will allow for checking passwords against the wiki's password
policy from the account creation and password change forms.
Bug: T111303
Change-Id: I0de281483bd83e47d80aa1ea37149d14f2ae5ebd
This passes the id of the revision that was undone to the
PageContentSaveComplete hook, since this hook is now inside a deferred
update so extensions can no longer rely on 'wpUndidRevision' being
present in the request.
Change-Id: I50dcb841cd0616acc2d69c3a685ba3cb339986c3
For mucking with the class member variable mNewContent and optionally
allowing the suppression of the "missing revision" message when revision
data is not found for a requested revision.
Originally implemented as the "GetUserMessagesDiffCurrent" hook (yes,
these three separate hooks in three separate places were essentially the
same) by Wikia for their SiteWideMessages extension.
Change-Id: Ie0c175af2af418d4ed3de28c94df918115312da3
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
This was added in I56b6600 in an attempt to work around a bug in
CentralAuth, but the bug has since been fixed in a better way. No hook
functions in Gerrit use the parameter (or ever have, as far as I can
tell), and anything that was passing a value other than the default
'login' has since been removed. So let's just get rid of it instead of
keeping it around doing nothing.
Change-Id: Ie604e03d268706221161ac93eb866f477e466fb4
Added for use in the CategoryTree extension to show the category count
on the special page, see If3815586c2a280b4e8958c13010c9f7436b8723d
Change-Id: If195fb55dee1350a6de095892ce89e6565287cd9
Also updated on mw.org.
This array never has language keys (at least not
unless other extensions add them) but core will
always just have numerical keys.
Change-Id: Ie9c42ac2b4ff143e36d07642f57cca769e8c00e7
The hook was removed in Ia8e17008cb9d9b62ce5645e15a41a3b402f4026a
The mentioned file in the documenation was renamed:
parserTest.inc -> ParserTest.php -> ParserTestRunner.php
Change-Id: I8fcf8302b84254d1dc5a3b629f425616bd1f5d13
The hook was readded with Iad2646acde79b8a59710bb9fd5fbbfea5a39c341
The text is from I2783c46c6d80f828f9ecf5e71fc8f35910454582
Change-Id: I5e26e0c9bef06e0a6213fd219bda58a61da80665
The main interface already has javascript enhancement to use
the API and mw.notify. This patch affects permalinks without
tokens, and opening the link without javascript.
This will match the current behaviour of action=watch.
Bug: T130946
Change-Id: I6be2c07824c17b165e068fc4ac36ab192e12bc9d
In order for an extension to add data to ApiQueryWatchlist, we need to
provide a way to allow it to manipulate the database query made by
WatchedItemQueryService. We also need some hooks in ApiQueryWatchlist to
handle the marshalling of data to and from WatchedItemQueryService.
To better handle hooking, this also moves some of the continuation logic
from ApiQueryWatchlist to WatchedItemQueryService.
Bug: T147939
Change-Id: Ie45376980f92da964a579887b28175c00fd8f57e
This allows extension to consistently use their WikiPage subclasses.
Currently the only way a subclass would be used is if Article::newPage()
was called.
Change-Id: I74cce5f9627c4bc4b92502aff74beb2daeb78d17
This will allow extensions to inject into the query to implement
"xxshow" parameters, and to add additional properties to the output
data for "xxprop" parameters.
Also, call these new hooks from ApiQueryRevisions, ApiQueryAllRevisions,
ApiQueryUserContributions, and ApiQueryRecentChanges since I701e8e19 is
going to be wanting them.
Bug: T143614
Bug: T143616
Change-Id: Id6b42c7f2eb53a6f659d0d61383287f41d96ca00
This creates a hook triggered when updating change tags, so that
extensions can take actions when tags are updated.
When tagging accompanies the action, the recent change is passed
while when tagging is subsequent to the action, the user who
performs the tagging is passed.
Bug: T118698
Change-Id: Ifb0cdc43252c4185e4f216d23b8a21fb31595a37
When it becomes impossible to load the content of a page due to some
error or misconfiguration, we still want to be able to delete that
page. This change makes WikiPage::doDeleteArticle more robust by catching
any exceptions that may be thrown while trying to load the page content
during the deletion process.
See T128466 for context.
Change-Id: I19f2d16850a3c1af5b504a70a27b9bf1330bc68d
Currently UsersPager::doBatchLookup() assumes that group data comes *only*
from one place, the (local) user_groups DB table. But this isn't correct
when an extension like [[mw:Extension:GlobalUserrights]] is installed.
With the current master version of the GlobalUserrights ext. installed
under MW 1.27, only the *local* groups are shown on Special:ListUsers.
Even if you have a global group called 'staff' and you go to the
[[Special:ListUsers/staff]] page, it *will* display the correct list of
users, but the group data in parentheses is wrong; it's either 1) missing
(if the user is only a member of a global group but not any local groups)
or 2) incorrect in that it omits global group membership(s) entirely.
With this hook, an extension such as GlobalUserrights is able to query an
additional source of user group data (such as the global_user_groups table
in $wgSharedDB in the case of the GlobalUserrights ext.) and have this
data stored in the cache to ensure that global group data shows up as it
should.
Change-Id: Ied2c0f2d5738cf96a66a9672182345d630285639
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
Most of the hook functions need context to see what the current user's
permissions are, to generate messages, or the LinkRenderer service to
generate the tool links.
Change-Id: I19fa27c8115ee39dded6cb98f29c35b66b934f8a
* Instead of having messy code to create a hidden HTML
comment of English strings at the bottom of the page,
expose the structured data of the parse information
to JS so tools can use it.
* Make makeConfigSetScript() use pretty output so these
variables are also easy to read in "view source".
* Remove ParserLimitReportFormat hook, since the data
is not formatted to HTML anymore.
Bug: T110763
Change-Id: I2783c46c6d80f828f9ecf5e71fc8f35910454582
This will help to differentiate between actual login and visiting
the login page while already logged in.
Bug: T140853
Change-Id: If8582ff61aee62b1d424e473b230ca883ddb6d05
Now with less fatals and more functionality! At least I sure hope so.
Unlike the first time around (https://gerrit.wikimedia.org/r/206642), the
DifferenceEngineRenderRevisionAddParserOutput and
DifferenceEngineShowEmptyOldContent hooks now only affect things if a
hooked function returns false. Since by default nothing is hooked into
these brand new hooks, the behavior should stay exactly the same as before
this patch and things like bug T139435 shouldn't happen anymore.
These hooks allow things such as:
* adding CSS(/JS) into the OutputPage when viewing diffs
* adding extra HTML content (such as avatars) into diff views
* hiding the bottom "mark as patrolled" link
* altering the parser output that is used by DifferenceEngine
* and more
Example extension using these hooks is wikiHow's
/extensions/wikihow/hooks/, specifically the file DiffHooks.php (but the
hooks are setup in WikihowHooks.php).
Live example of the DiffHooks stuff in action can be found at wikiHow.com,
for example:
http://www.wikihow.com/index.php?title=Set-Your-Homepage&diff=17112892&oldid=15888129
(user avatars, additional CSS, changes to the old/new revision header
texts/links)
Bug: T139526
Change-Id: I10293be4581140c3edf0e4b538b04b31cb6f5730
This paramater contains a map of id => old and new visibility bits.
This allows doPostCommitUpdates to do something useful with the
differences before and after a visibility change. Specifically,
RevDelRevisionList doPostCommitUpdates passes this to the
ArticleRevisionVisibilitySet hook.
Bug: T137287
Change-Id: I1824f56d2aadc15671c442cf30dc1f9f01e821f8
The new hook runs at the beginning of UploadBase::performUpload().
Unlike the existing UploadVerifyFile hook, the new one provides the
information about the file description page being created, and the
user who is performing the upload. It also does not run for uploads
to stash.
The action=upload API and Special:Upload have been changed to treat
errors from UploadBase::performUpload() as recoverable, which means
that they will attempt to stash the file (previously they would require
the user to upload it again). This is mostly intended for errors from
the new hook, but I think it makes sense for the existing ones, which
are mostly transient filesystem erorrs.
Bug: T89302
Change-Id: Ie68801b307de8456e1753ba54a29c34c8063bc36
These hooks allow things such as:
* adding CSS(/JS) into the OutputPage when viewing diffs
* adding extra HTML content (such as avatars) into diff views
* hiding the bottom "mark as patrolled" link
* altering the parser output that is used by DifferenceEngine
* and more
Example extension using these hooks is wikiHow's
/extensions/wikihow/hooks/, specifically the file DiffHooks.php (but the
hooks are setup in WikihowHooks.php).
Live example of the DiffHooks stuff in action can be found at wikiHow.com,
for example:
http://www.wikihow.com/index.php?title=Set-Your-Homepage&diff=17112892&oldid=15888129
(user avatars, additional CSS, changes to the old/new revision header
texts/links)
Change-Id: Icbc987fa4806e7bfc66743375301912b428dc348
Since this updates happens post-send or via the job queue, the
page object will be for a non-existing or newer page/redirect.
Change-Id: I20b583948157dccceca6eb1fbd25121822bf1b2f
This allows extensions (e.g. TemplateSandbox in I77a9aa5a) to better
interact with the ApiParse and ApiExpandTemplates modules.
Change-Id: I72d5cf8e0b86e4250af1459219dc3b42d7adbbb8
This gives finer-grained extensibility than the current ContributionsLineEnding
hook.
Bug: T122537
Change-Id: Ifca9f3f3b838a2915152f0200624ef40ee3f8a19
There is no place for a type before the variable name
Follows 9ec1ef7308 (security patch not in gerrit)
Change-Id: I7c2718f8026c7163553b9135362e5de61a26c9f8
This may negatively affect performance and the whole purpose of the
hook (making it possible to reject an edit from an extension while
providing detailed error information in the API result) has been
invalidated by 09a5febb7b, which lets
EditFilterMergedContent do this too.
I think it was intentional that the hook was called with just the text
passed to action=edit API. Making it actually be called with the text
that's going to be saved would require more work (e.g. for
automatically resolved edit conflicts, T73947).
Very few extensions use this hook. I'm fixing AbuseFilter to use
EditFilterMergedContent in I30c1e3d0a6c10888e6ac53745313434474663cce,
we should also review ConfirmEdit, ProofreadPage and SpamBlacklist to
see what behavior they really expect.
This reverts commit be97167ab6.
Change-Id: I62713419496bcf57364a8fa9de93c0c8ddc3e91c
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
The header is intended for use with XMLHttpRequest when the request
might be part of an XSS. The hook is for extensions that might need to
add additional checks of some sort.
Bug: T98313
Change-Id: I0e5f2d3b29a79a12461dc33c90c812a56810f536
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
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
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
(This is part of I6ec374ac9 wich was a re-submit of Ie98bf5af5
which got reverted by Ide7ab563)
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* integration tests (which most of the existing phpunit tests are)
In contrast to I6ec374ac9, this change does not cause singeltons
of legacy services to be reset. It is assumed that legacy services
use global state to access services and configuration, so any
change in confuguration would affect them immediately.
NOTE: the original I6ec374ac9 would cause session information to
get lost if the user session was creatsed before initialization
was complete. This was apparently triggered by the MobileFrontend
extension under some circumstances. Check with Addshore and Catrope.
Change-Id: Ie06782ffb96e675c0aa55dc26fb8f22037e8517d
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* forking processes
* integration tests (which must of the existing phpunit tests are)
Depends-On: I5d638ad415fc3840186a0beaa09ac02ea688539b
Change-Id: Ie98bf5af59208f186dba59a9e971c72ea0b63e69
The service locator, MediaWikiServices, is intended to facilitate
"manual" dependency injection in static entry points.
See also the Dependency Injection RFC T384 and Service Locator
RFC T124792 for details.
The following key points were implemented according the
discussion surrounding these RFCs:
* a configurable DI container that allows extensions to add and replace services.
* no auto-wiring, since it's prone to add confusion in large and complex applications.
* no 3rd party framework, since they typically do too much.
The following services in MediaWiki core are made accessible via the service locator
mechanism to showcase the bootstrapping mechanism:
* ConfigFactory and MainConfig
* SiteLookup and SiteStore
However, the implementation of these services was not yet converted to using proper DI
throughout the code.
Bug: T124792
Change-Id: I3c25c0ac17300d3dd13e1cf5100558a605eee15f
Allos SpecialPage::beforeExecute() (and the equivalent
SpecialPageBeforeExecute hook) to prevent execution of the page
by returning false.
Needed by I8b52ec8ddf494f23941807638f149f15b5e46b0c.
Change-Id: I71423b920d596ee9ae6da60d95b14255eddfbcd6
Via the argument given by Krinkle in
https://gerrit.wikimedia.org/r/#/c/274751/1/ImageMap_body.php
Quote: "[Returning true is] obsolete for a while and slowly disappearing
from existing code. Only 'return false' is an explicit signal. The
default is true. This was done because it very often is forgotten and
causes broke in production in catastrophic ways on numerous occasions.
This better reflects the mental model of intent and also makes it more
natural when dealing with hooks such as these, which can't be aborted
and as such don't have a sensible purpose in returning false, which
means returning true can be confusing."
Change-Id: I98308ed9105d904e47db3ac7899412f239c2bf9d
Adds a few pieces of information to improve tracking of autocomplete
usage.
* When using Special:Search 'go' feature forward wprov parameter to redirect
* Include a data attribute indicating autocomplete location to
differentiate usage of the header and Special:Search content autocompletes
* Report exact query string that was used for impression-results
* Add handling to allow searchSuggest subscribers to append tracking
information to generated article links
* Add a new hook, SpecialSearchGoResult, that can either change the url
redirected to in the 'go' feature or cancel it entirely.
Bug: T125915
Change-Id: Iec7171fcf301f1659d852afa87ce271f468177c1
This is a pre-requisite to fix a Flow move regression, T127785.
This allows running an atomic entirely within the move with the correct
ordering.
Bug: T127785
Change-Id: Ie772f737f917854e4cfefe52ec3bea4669c9efe0
* check 4 new paths
* strip 'NormalizeMessageKey' hook from docs/hooks.txt,
last call was removed in 1ea4f23b05
Change-Id: Id36ab478b94f74be451cae848d5ef2a318d23040
Pass the cookie options by value to WebResponseSetCookie handlers so
that they may alter them.
Bug: T49647
Change-Id: I69ae55baa7806f14726b0b08215c0df471794b39
The plan here is to take it out of 1.27.0-wmf.12 and put it back in
1.27.0-wmf.13.
Since BotPasswords depends on SessionManager, that's getting temporarily
removed too.
This reverts the following commits:
* 6acd424e0d SessionManager: Notify AuthPlugin before calling hooks
* 4d1ad32d8a Close a loophole in CookieSessionProvider
* fcdd643a46 SessionManager: Don't save non-persisted sessions to backend storage
* 058aec4c76 MessageCache: Don't get a ParserOptions for $wgUser before the end of Setup.php
* b5c0c03bb7 SessionManager: Save user name to metadata even if the user doesn't exist locally
* 13f2f09a19 SECURITY: Fix User::setToken() call on User::newSystemUser
* 305bc75b27 SessionManager: Don't generate user tokens when checking the tokens
* 7c4bd85d21 RequestContext::exportSession() should only export persisted session IDs
* 296ccfd4a9 SessionManager: Save 'persisted' flag in session metadata
* 94ba53f677 Move CSRF token handling into MediaWiki\Session\Session
* 46a565d6b0 Avoid false "added in both Session and $_SESSION" when value is null
* c00d0b5d94 Log backtrace for "User::loadFromSession called before the end of Setup.php"
* 4eeff5b559 Use $wgSecureCookie to decide whether to actually mark secure cookies as 'secure'
* 7491b52f70 Call session_cache_limiter() before starting a session
* 2c34aeea72 SessionManager: Abstract forceHTTPS cookie setting
* 9aa53627a5 Ignore auth cookies with value 'deleted'
* 43f904b51a SessionManager: Kill getPersistedSessionId()
* 50c5256352 SessionManager: Add SessionBackend::setProviderMetadata()
* f640d40315 SessionManager: Notify AuthPlugin when auto-creating accounts
* 70b05d1ac1 Add checks of $wgEnableBotPasswords in more places
* bfed32eb78 Do not raise a PHP warning when session write fails
* 722a7331ad Only check LoggedOut timestamp on the user loaded from session
* 4f5057b84b SessionManager: Change behavior of getSessionById()
* 66e82e614e Fix typo in [[MediaWiki:Botpasswords-editexisting/en]]
* f9fd9516d9 Add "bot passwords"
* d7716f1df0 Add missing argument for wfDebugLog
* a73c5b7395 Add SessionManager
Change-Id: I2389a8133e25ab929e9f27f41fa9a05df8147a50
User keeps most of its token-related methods because anon edit tokens
are special. Login and createaccount tokens are completely moved.
Change-Id: I524218fab7e2d78fd24482ad364428e98dc48bdf
ImportLogInterwikiLink. Hook to change the interwiki link used in log entries and edit summaries for transwiki imports.
Change-Id: I03e054de16d8820c0f3d2c165288e229960d6bb1
SessionManager is a general-purpose session management framework, rather
than the cookie-based sessions that PHP wants to provide us.
While fallback is provided for using $_SESSION and other PHP session
management functions, they should be avoided in favor of using
SessionManager directly.
For proof-of-concept extensions, see OAuth change Ib40b221 and
CentralAuth change I27ccabdb.
Bug: T111296
Change-Id: Ic1ffea74f3ccc8f93c8a23b795ecab6f06abca72
Also fix USE INDEX so that it won't break if another table is joined.
See related change at I2a7003f9.
Bug: T53124
Change-Id: I9ac910bc4c24196b1f19e2fc7f1e5b88a0dac41b
The EventBus extension needs to forward the created (null) revision ID as
part of the page move event. Looking this value up when the hook fires is
problematic, because without a connection to the master DB the query might
very well return nothing (if it races in before the entry is replicated to
the slave).
This changeset passes the newly created Revision on to the hook so that it
doesn't need to be queried separately.
Bug: T116786
Change-Id: I1b48e2904fc8d99f2cde604f274f79a2b47d7fc2
The next revision in the page history isn't necessarily the previous
revision (due to selective undeletions, history merges, etc). This
passes the next revision to HistoryRevisionTools so extensions can check
if needed. Also, it passes the user to this hook and DiffRevisionTools
to avoid use of wgUser or having to retrieve context.
Change-Id: Ibc68f19040eebe3614e07f753f26bbfd376ae28d
* All updates for an event are atomic for the main DB.
* This follows-up 9e51328790 by reverting the auto-commit
behavoir which was a side-effect of that change.
* Added TitleMoveCompleting hook with is a pre-commit version
of the same hook. Various extension could benefit from the
atomicity of running in the main transaction.
Change-Id: Ife5990bbedca1de78bcf83f2d6fdeeae8086ffad
Check if all hooks in hooks.txt have a &, if the code also have & and
the other way round.
Fix all hooks in hooks.txt to have a clean run of the script.
Change-Id: I1b45253e20dc310e825cdc17e0e2e9c8fb315bab
Using the new system introduced in
1c57794e37 (see T47843).
This change allows Title::getUserPermissionsErrors() to include
MessageSpecifiers instead of string message keys in its return value.
This doesn't seem to have any bad effects, and should work seamlessly as
long as callers aren't trying to do anything stupid and just pass the
value to PermissionsError or OutputPage::showPermissionsErrorPage()
or wfMessage() or some such.
If the callers *are* trying something stupid, nothing worse than
duplicated or otherwise less-than-perfect error messages (in code
which tries to handle some message keys specially) should happen.
(I fixed wfMergeErrorArrays(), but who knows what else lurks in all
this code.) Any problems should only affect new-style errors using
MessageSpecifier, though.
Since MessageSpecifiers tend to be stringable, we probably won't get
fatals, but might get incorrect checks. Should we try to log this
happening somehow?
Goes with I42a0c5b0ea7e61088dd609b764dd7d1396c60cd5 in TitleBlacklist.
Bug: T115258
Change-Id: I1334ba21a2862973a9d8ff5be2c9bec06a82698b
BaseTemplateAfterPortlet: Add colon to match the other arguments
FileUpload: Adjust spacing to match the other arguments
Change-Id: Iae0285b1a39cf851aaaa735cb22e95c839813997
We should be telling extensions whether a deletion is a suppression or not, so
they can behave appropriately.
Change-Id: I2cb6ffd61dd12766fe0266514c9360ff0c90b788
UserMailerTransformContent allows extensions to change the body of
an email sent via UserMailer::send(). This is applied before
low-level transformations such as multipart or content encoding.
UserMailerTransformMessage is similar but it is run after those
transformations.
UserMailerSplitTo allows extensions to request that a certain
user should always be emailed separately (so when UserMailer::send()
is called with an array of target addresses, that user will be split
out into a separate call). This is intended for content
transformations which need to be different per user, such as
encryption.
A side effect is that while before a call to UserMailer::send() was
either fully succeeded or fully failed, now the message might be
delivered to some targets but not others. send() will return a failed
Status object in those cases.
Bug: T12453
Change-Id: I4c3a018110173c3b5d52a753fdcbec397b590ced
Very useful to do things that need to know the actual search
term (eg. to show further things related to that).
The old hook supported that as well, as documented on
https://www.mediawiki.org/wiki/Manual:Hooks/SpecialSearchResultsAppend
That hook has been re-introduced with e7551f16
Change-Id: I7ac6ad95b29f9da0802eb3340e27b8683bf9f76d
The last two parameter were not in documentation.
Follows 3c8c735c56 (r11803)
Follows 06be63aa1c (r28125)
Change-Id: I4fe91a6ad714ef06a187f7cd873fda5237103d2c
The last parameter is not in code, so remove it from documentation.
Was removed with a35fcb0bed (r12207)
Change-Id: I5625f621342c2b71c56df3b3167479ec3884acf8
Currently import sources have to be set into $wgImportSources as part of
wiki startup. This is not practical for the WMF cluster, where we need some
reasonably complex logic to set up the import source structure.
This change allows the import source list to be populated from a new
"ImportSources" hook. This hook is only called when the list of import
sources is actually needed (namely, when a user with relevant permissions
loads Special:Import).
Bug: T17583
Change-Id: Ice9a19cb6dfe53ae72aa71353d0553ee9338f233
This allows extensions (e.g. Echo) to detect who made the change without
relying upon $wgUser. It also allows for differentiation between
autopromotion entries which will pass in `false` as the performer.
Change-Id: Idebd78b54dcea1bdc84c83f402e87b240ab4ade1
Document the missing $error parameter of the EmailUser hook.
Clarify the type of the address parameter
Also add an comment, why a variable is used twice
Follows 38c7c8f895 (r64903)
Change-Id: I1c5636dc378667ef2798c69659b43f70734f4144
* LocalUserCreated: Replaces AuthPlugin::initUser()
* UserGroupsChanged: Replaces AuthPlugin::updateExternalDBGroups()
** The similar UserRights hook is deprecated, mainly to get rid of the
passing of $user by reference.
* UserIsHidden: Replaces AuthPluginUser::isHidden()
* UserIsLocked: Replaces AuthPluginUser::isLocked()
* UserLoggedIn: Replaces AuthPlugin::updateUser()
Also, AuthPlugin::updateExternalDB() is deprecated in favor of the
existing UserSaveSettings hook.
Also, 'ResetSessionID' has been removed. Nothing uses it, I don't know
why I even added it in the first place.
Also, replacing the User object passed to AuthPlugin::initUser() and
AuthPlugin::updateUser() will now raise a warning.
Change-Id: If7474cfb26a29b11c2e78147069419ca3b1cba95
mw.ForeignApi is an extension of mw.Api, automatically handling
everything required to communicate with another MediaWiki wiki via
cross-origin requests (CORS).
Authentication-related MediaWiki extensions may extend it further to
ensure that the user authenticated on the current wiki will be
automatically authenticated on the foreign one. A CentralAuth
implementation is provided in I0fd05ef8b9c9db0fdb59c6cb248f364259f80456.
Bug: T66636
Change-Id: Ic20b9682d28633baa87d22e6e9fb71ce507da58d
Allow callers to specify why they are checking a passwords validity, so
some checks can be modified. Only check the default policy on creation,
since the account doesn't exist it's not a member of any groups.
Bug: T104615
Change-Id: I56b66002562aaa1493d94a90309bc8e4ae3841c8
Introduce a new hook to allow (single) block-level entries.
Very similar to EnhancedChangesListModifyLineData.
Bug: T104399
Change-Id: I6b4715277d44e5f09d7a230b33e956676aeab1c2
Gives extensions a chance to modify the data used to
build each enhanced recent change 'inner' lines
(as opposed to the header lines).
Bug: T102021
Change-Id: Ia8a796fb9621db14d6574e66a4572e1fdf3bad03
Add a new hook, 'RejectParserCacheValue', which allows extensions to reject an
otherwise-successful parser cache lookup. The intent is to allow extensions to
manage the eviction of archaic HTML output from the cache.
Change-Id: I660679a48c46608f859bd52b31d6a888aabcc9ac
This allows additional HTML to be included below search results. This
will be used to optionally include a feedback link fter search results.
Bug: T101783
Change-Id: I5c4bab12ed0b022c84aa6b50ab72635e9dd0bd0c
Make password policies defined in a configurable policy, which is
defined by group. A user's password policy will be the maximum of
each group policy that the user belongs to.
Bug: T94774
Change-Id: Iad8e49ffcffed38df6293db0ef31a227d3962003
* Line wrap at 80 columns
* Added missing '$' for pass by reference parameters
* "$param_name: ..." for all params
* Parameter descriptions that wrap have a 2 space hanging indent
* "DEPRECATED! Use ..." immediately follows hook name
* Indent code examples with tabs per MW coding standards
* Move "hanging" information into description headers
* Fix some really out-of-order alphabetizations
Change-Id: Ic5453c90fb9b58e9fc137d8f45dcd255957bf76d
Rationale: give extensions a way to track which "renderings"
of a page exist in the cache. This is particularly relevant
for multi-lingual wikis that splpit the parser cache by user
language on some pages. In that case, hooking into
ParserAfterParse or LinksUpdateComplete is insufficient to
track all language specific renderings.
Bug: T99511
Change-Id: Iebf526098ca837a7df637c650097119495000c81
These hooks are unused in all extensions in Gerrit. We need to remove
them so we can move these classes into a separate library.
Change-Id: I66406c642168adc703361b75deb95c830c1ddab1
This allows the user of the SpecialStatsAddExtra hook to provide
formatting for the row label using an i18n message key. If given, the
message is given the row key as a parameter. To maintain backward
compatibility, the key is used as-is as was done previously if a message
key is not provided.
Bug: T97623
Change-Id: I43c522b24372e115ed78adf69848bf50cbab8295
When adding strip markers, allow closures to be passed in place of text.
The closure is then called during unstrip. Also, add a hook that runs
after unstripGeneral. This is needed for Extension:Cite's I0e136f952.
Change-Id: If83b0623671fd67e5ccc9deaaaab456a6679af8f
The intention of the new hook is to allow extensions to prefetch
any information that may be needed for displaying history rows.
In particular, this is needed by Wikibase to allow us to inject
localized entity labels into the edit summaries.
Bug: T95672
Change-Id: Ie10ef99154da35713a4f583e2de2162fba28eef2
Enhanced RC generates these "(3 changes | history)" links for
every block of grouped recentchanges. That changes-link links
to a diff page.
For Flow, that is all wrong: we have different ids (not integers),
on a different page (&curid=&oldid=&diff= means nothing). Even
the concept of a "diff" page seems wrong here for us - a new post
is not part of some document that can be diffed.
In short: we'll want to generate a different link, and we'll need
a hook to let us change them.
Meanwhile also split the code that generates those links into a
separate method.
Bug: T72513
Change-Id: Ib32fb9552b80f9581d89b3b47da6e5d32e3d84a3
So that we can determine whether a save attempt succeeded or failed,
to log saveSuccess and saveFailure events from the server to Schema:Edit
on meta.
Bug: T88027
Change-Id: Ib861262603872e67600d1aab9bde3b58a8dd1738
This is a hard deprecation, with getSecondaryDataUpdates returning an
empty array and addSecondaryDataUpdate throwing an exception. This seems
prudent since there are no known users of these methods, and they
interfere with the parser cache:
DataUpdates are basically jobs, they need access to services to
function. That makes them inherently non-serializable. This interferes
with the function of the parser cache, which serializes ParserOutput
objects in order to persist them.
This could be solved by splitting DataUpdates into DataUpdateDefinitions
and DataUpdateHandlers, similar to how JobSpecification works with
wgJobClasses. That however seems pointless and overkill, since
ParserOutput already has a mechanism for storing arbitrary data,
including any info needed by an UpdateJob: the setExtensionData method.
After this change, the preferred method to introduce custom data updates
is to store any relevant data using setExtensionData and
implement Content::getSecondaryDataUpdates() if possible. If not,
use the 'SecondaryDataUpdates' hook to construct the necessary update
objects from the info stored using setExtensionData.
Change-Id: I0f6f49e61fa3d8904e55f42c99f342a3dc357495
Needed to conditionally register API modules. The previous way, messing with globals
from extension functions, is getting problematic because Config class will make this
impossible.
Change-Id: I86b40aeec555dd6b3cd82cab31d96e85fdf0a665
Patch adds two hook which are described in hooks.txt. This
is being used to allow Flow to offer two links instead of just
one that are relevant to the page that was categorized.
The default output without these hooks is:
<a href="...">Topic:Soiasdf90f09</a>
This patch allows flow to provide context as to where this topic came
from, by replacing that with:
<a href="...">Topic:Soiasdf90f09</a> on <a href="...">Talk:Help</a>
(Note that the names of pages within the Topic namespace will also
become more friendly soonish, but outside the scope of this patch).
Bug: T87793
Related-Flow-Change: Ia4f2953bcd807ba3990e762a2efcaab428c40147
Change-Id: I182e6e35fcc3a2a298e928e088579bdb22e145ff
The old hook supplied a way to override the HTML used for the section link,
but two extensions both trying to use it was obviously not going to work.
Deprecate it in favour of a hook that goes around gathering info to build
the initial HTML, then shoves it through the old hook for back-compat.
So that WikiEditor can add in extra URL parameters as well as VE adding in it's
own link.
Bug: T88027
Change-Id: I5a7a23709805625bdefb69cd9379be0c95acd982
Add new hook (ResourceLoaderGetLessVars) called in ResourceLoader::getLessVars to
allow context-based less variables. Cache the resulting array to avoid multiple runs
of this hook.
Change-Id: I5a73bbd0ab58f8fe34519931c4f26c90998e3451
This allows users with the `managechangetags` right to create tags for
use by wiki users. (Currently there is no way for editors to apply tags
to their edits; that's to come in a later patch.)
Extensions can reserve tag names for their own use, even if they do not
define them or mark them as active.
Tag managers can also delete tags with <= 5000 uses. Currently, if a tag is
misspelt ("vandlaism") or no longer wanted (testing of OAuth, etc), the
wiki is stuck with it forever. This change allows users with the
"managechangetags" right to delete change tags from the database,
including removing them from all revisions to which they are applied.
Obviously this is a powerful thing to be able to do, but I view change
tags as a "light" kind of interface, useful for revision patrolling and
spam/vandalism fighting but not something that necessarily needs to hang
around forever. It's not a big deal for this kind of data to be thrown
away without being archived anywhere.
Tags defined by an extension can only be deleted if the extension allows
it.
Changes to tags are logged in the new "tag management" log. There's even
a nice API module, just for fun.
Bug: T20670
Change-Id: I77f476c8d0f32c80f720aa2c5e66869c81faa282
ContribsPager, which is used by ApiFeedContributions, can return more
than just revision rows. This is handled in the html side within the
ContributionsLineEnding hook. ApiFeedContributions had no special
handling so here I have added a simple hook the provides the data
from ContribsPager and allows subscribers to provide the appropriate
FeedItem instance.
Bug: T85229
Change-Id: I27c77cc682ba801c40361c76b67398108ca1a592
Before r39373, all autocomments in an edit summary were formatted. In
fixing a bug with page titles containing "/*" this was accidentally
broken.
To use a single preg_replace_callback call to replace multiple
autocomments, we need to make sure that the match of one autocomment
doesn't overlap the match of another, which means we can't have "(.*)"
before and after. But we do still need to detect whether there is
anything before or after. "(?=(.?))" and "(?<=(.?))" would do nicely,
except the latter isn't actually supported. "(?=(.))?" and "(?<=(.))?"
work too, but older versions of PCRE don't support that. They do,
however, support "(?:(?=(.)))?" and "(?:(?<=(.)))?", so that's what
we'll go with.
This change does change the values for $pre and $post passed to the
FormatAutocomments hook; extensions need to be updated to accept (and
not prepend/append) booleans for these parameters.
Bug: T18530
Bug: T70361
Change-Id: I36c3a9e548a4ef72f93974bb35f9add8c29e9287
By placing the notice "If 'broken' is a key in $options
then the file will appear..." added by Aaron Schulz with
commit 9d572d1844.
This solves a 'FIXME' added by Siebrand Mazeland with
commit b33c77a525.
Change-Id: I9d100588276faac5d5b2be979d8140389e5ed85a
Up until now, the import backend has tried to resolve titles in the XML
data using the regular Title class. This is a disastrous idea, as local
namespace names often do not match foreign namespace titles.
There is enough metadata present in XML dumps generated by modern MW
versions for the target namespace ID and name to be reliably determined.
This metadata is contained in the <siteinfo> and <ns> tags, which
(unbelievably enough) was totally ignored by WikiImporter until now.
Fallbacks are provided for older XML dump versions which may be missing
some or all of this metadata.
The ForeignTitle class is introduced. This is intended specifically for
the resolution of titles on foreign wikis. In the future, an
InterwikiTitle class could be added, which would inherit ForeignTitle
and add members for the interwiki prefix and fragment.
Factory classes to generate ForeignTitle objects from string data, and
Title objects from ForeignTitle objects, are also added.
The 'AfterImportPage' hook has been modified so the second argument is a
ForeignTitle object instead of a Title (the documentation was wrong,
it was never a string). LiquidThreads, SMW and FacetedSearch all use this
hook but none of them use the $origTitle parameter.
Bug: T32723
Bug: T42192
Change-Id: Iaa58e1b9fd7287cdf999cef6a6f3bb63cd2a4778
ConfirmEdit was tripling the amount of time it took to save a typical
page via the API, since it was assuming that the APIEditBeforeSave hook
was giving unmerged wikitext, requiring a full parse of the content
before and after the edit in order to check the addurl trigger.
Apparently nobody bothered to update it after Ia59fb6bb.
APIEditBeforeSave is unusable anyway, because it is given the serialized
content, without any information about the content model. It really
needs the Content object in order to do it properly. So instead, adapt
EditFilterMergedContent for the purpose. Incidentally, that avoids the
inelegant defined('MW_API') check in ConfirmEdit's
EditFilterMergedContent handler, since both API and normal edits are
handled by EditFilterMergedContent in the same way.
Unfortunately the interpretation of the 'value' member in the Status
object passed to EditFilterMergedContent is not extensible, being an
integer instead of an associative array. So we add a custom member in
order to get the result array back down the stack.
Another obstacle to this design was the lack of an EditPage object
passed to EditFilterMergedContent. ConfirmEdit was previously directly
calling EditPage::showEditForm() with a $formCallback which outputs the
necessary HTML. Instead, I hacked up runPostMergeFilters() a bit, to
allow the hook to request that the edit page be shown again even if
hookError is not set. Then a new EditPage::showEditForm:fields hook does
the necessary HTML output, instead of $formCallback.
Marked $formCallback as deprecated, since I think it is now unused.
Change-Id: I4b4270dd868a643512d4717927858b6ef0556d8a
They're currently documented as a 'compatibility hook'
in docs/contenthandler.txt. No longer used in any Wikimedia-hosted
git repository.
Superseded by the ContentHandlerDefaultModelFor hook.
Change-Id: I212230da7d6080cf500f930d4aa5a9024959d5f9
There's really no reason for the extension to exist separately from
core, and merging it reduces the risks of bitrot in both the extension
(lots of deprecated functions there) and core (missing integration with
PageImages and TextExtracts, for example).
Change-Id: Ie0ab90902ede9499879402290006466efba479e9
The new Extension:WikEdDiff is a custom inline difference engine.
There is currently no hook to integrate custom difference engines.
This patch adds a new hook called 'GetDifferenceEngine' in
/includes/content/ContentHandler.php in function
'createDifferenceEngine()'.
Passed variables:
$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: output parameter, difference engine object to be used
for diff
If the hook handler returns false, a valid difference engine object is
returned in the passed-by-reference variable $differenceEngine.
If the handler returns true, the default engine is used as fallback.
The specified diff engine class will typically be an extension of the
class DifferenceEngine (includes/diff/DifferenceEngine.php) with
modifications, e.g. of function generateTextDiffBody() and
__construct() (without deprecated parameter $rcid).
Also fixes a missing declaration in DifferenceEngine that is required for
extending this class.
Bug: 71916
Change-Id: I9da63c1ceb339bfeba7beddc712be51977b95f65
Add hook LoginFormValidErrorMessages to allow extensions, to add own valid
error messages to redirect to the login form.
Bug: 71769
Change-Id: I9e996a88e3972f09946726060916a21124de049c
* AbortMove hook is removed in favor of two more specificly focused
hooks: MovePageCheckPermissions and MovePageIsValidMove.
** MovePageIsValidMove is for extensions to specify whether a page
cannot be moved for technical reasons, and should not be
overridden.
** MovePageCheckPermissions is for checking whether the given user
is allowed to make the move.
* Title::moveNoAuth() deprecated
* Title::moveTo() deprecated
* Title::isValidMoveOperation() broken down into
MovePage::isValidMove() and MovePage::checkPermissions().
* Title::getTitleProtection() is now public, and returns
unprefixed fields
Change-Id: Ic5026384b92a0d68d628397ffe1de6e5b6183f02
* SpecialLogAddLogSearchRelations
Allows for adding the extra conditions needed by the query
* LogEventsListGetExtraInputs
Allows for adding extra input fields to interface
Bug: 70850
Change-Id: If8bdbadd882d67cae82c862c7c38000e9329b04f
This will allow extensions (namely CirrusSearch) to match namespaces using
their own rules if core can't find the namespace on its own.
Bug: 62322
Change-Id: I17337cd8ce90190bd335c9159e9d3bbb39ba89cd
The UnitTestsList hook can now be used to add entire directories of
tests, à la phpunit.xml's <directory> tag. The test suite is built by
recursively scanning the directory for any files ending in "Test.php".
TODO:
* Update online hook documentation.
* Generate and autoload a classmap for scanned directories.
Bug: 70630
Change-Id: I3089372f9d7c645e16ff0984a959f982a3bc639f
The syntax highlighting applied to the XML format is not all that great,
and applying it to other formats is just wrong. Instead of doing it
ourselves, let's just add a hook and let Extension:SyntaxHighlight_GeSHi
do it for us.
But for that to work, we have to add RL support to the pretty-printed
output, which means OutputPage. At the same time, lets internationalize
the header.
Bug: 65403
Change-Id: I04b1a3842abdf1fb360c54aa7164fc7cd2e50f4b
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
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
Needed for MobileFrontend on third-party sites that use this feature.
Ideally, there should be a way to cache mobile requests too, but that's
a different issue requiring much more effort to do properly.
Bug: 68106
Change-Id: I01a76c571d9186b325f19a00cec136459707c791
Hook handlers should have access to the OutputPage object,
so they can use information stored there for generating
language links. This is needed to allow efficient generation
of "badges" by the Wikibase extension.
Change-Id: Ic479e2fa5cc3a4d663e478858caee2742e6805b9
Provide a way for extensions to nicely handle when a username doesn't
exist, during the login process. This only is obviously only for the
case when we know why it doesn't exist (it was renamed, deleted, etc.)
See I06b9b6322e408868f516aeabd61c6580f304e009 for CentralAuth use case.
Bug: 67995
Change-Id: If48d59afa63ace68c147eca952f1d4f43acc105f
Currently LocalisationCache merges the core data for all languages in
the fallback chain, then the extension data, then merges those two, and
then gives extensions like LocalisationUpdate a chance to make final
overrides with the LocalisationCacheRecache hook.
But if LocalisationUpdate doesn't want to locally duplicate all the
messages for every language (e.g. r104041), LocalisationCacheRecache is
too late: the information as to whether a message came from the primary
language or a fallback has been lost, so when LU itself has an override
for a fallback language it can't know whether or not the existing
message should be overridden or not.
The solution is for LocalisationCache to gather the data for each
fallback language separately, call a new hook for LU to affect just that
language (LocalisationCacheRecacheFallback), and only then merge the
fallback languages together.
Bug: 68781
Change-Id: Iacfe96063fcc66c1f97ca5e5292a8fc70af988cf
The former hook is only used by one extension which uses the
same code path for both hooks meaning no fix is necessary. Makes
it possible for extensions to actually provide results when none
were found.
Change-Id: Ia4d56b2a1a7531529dbde8a011a33a4482c04932
The current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
This will allow subscribers to batch-load everything they
need beforehand, instead of loading everything piecemeal
on a per-line basis when WatchlistEditorBuildRemoveLine
is called.
Change-Id: I362e25b585921d755d6564955ac685971386f29b
Flow, for example, has those totally illegible Titles like
Topic:S0gx52fzru1680ib - instead, we'd rather use the topic
title content as link text.
Change-Id: I30b3bbb2c5ef131f069a5aabfad8b88bc2cf09df
Added includes/skins/ to the list of directories and removed
the skins that were moved out of core.
The MonoBook hook is moved to skins/MonoBook in Ieb85b4bed.
Change-Id: Ie8ad1eb694575b8e1485177e2d14f2a9dcab179d
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
After some discussion with Roan, it turns out this
hook is unnecessary. The proper solution is to use
addModuleScripts/addModuleStyles instead of a
plain addModules.
This reverts commit e7361de181.
Bug: 68712
Change-Id: Iadbff5f7fbbc5a08d6336674b12315967f45591d
Removed hook definitions for UserComparePasswords
and UserCryptPassword, rather than keep them in
the file.
Bug: 28419
Change-Id: I7bfda155986d1407caef4e3890024c5b8a66fdcc
Follows-up: I0a9c972931a0eff0cfb2619cef3ddffd03710285
Deprecated the old User::crypt, et. al password hashing
system and implemented an extensible password hashing
API.
The new Password class allows registering of child classes
and provides factory functions for creating new Password
objects. The built-in hash types are the old MediaWiki MD5
types, which are for backwards-compatibility only, and bcrypt.
Also included is support for wrapping existing hashes as well
as encrypting passwords with a configured encryption key.
Bug: 54948
Bug: 28419
Change-Id: I0a9c972931a0eff0cfb2619cef3ddffd03710285
Deprecated only since 1.23, but universally reviled, and used only by
MwEmbedSupport, which no longer uses it as of I43af3c87a).
Change-Id: I36c89b273fdb0ec3a76034c7a6d2f48a15d5457f
* By default, wiki should keep the envelope sender as $wgPasswordSender
* Requires BounceHandler extension. Added hook to core
* Alters the return path, to bounce-{key}@domain
* The envelope sender is set using the 5th param in mail()
Bug: 46640
Needed By: I9463ae33ae327405725ea9693d45ad61b8ecf798
Change-Id: Ic5c1231611a5c4984ddf81fd716e6f3a3e82fd57
Location is a tad bit different now than on the wikiHow codebase and some
arguments have been added, as per code review.
Because sometimes you have things that are stored in the user_properties
database table that should *not* be reset even when the user has requested
to reset all prefs back to the site defaults.
Live example of a thing using this hook (well, its previous iteration) is
wikiHow's WikihowPreferences extension.
Change-Id: I1da936c786adb21e2c1802ef405bb904c9cf4918
Adding 3 hooks to MimeMagic.php
- MimeMagicInit: Add assignments of MIME types -> Media types
and assignments of MIME types -> File extensions
- MimeMagicImproveFromExtension: Further improve the MIME type detected
by considering the file extension
- MimeMagicGuessFromContent: Guess the MIME from file content
This is the successor of Icf9eec10bec7c0a7e.
PHP's own module fileinfo module is not capable detecting Chemical
table files. Instead, they are reported as text/plain.
MediaHandlers can be attached by MIME type only. That's why these
changes are required for [[Extension:MolHandler]] to work.
Clean up:
Do not create unused property MimeMagic::mToMime.
Change-Id: I67f3e4e83b47e6df0d9e8371f09a741a8aa77651
