getCheckboxes() directly generated the HTML for the
"This is a minor edit" and "Watch this page" checkboxes,
and allowed extensions to add more HTML checkboxes (and
modify existing ones) using the 'EditPageBeforeEditChecks'
hook. This prevents us from ever changing the format of
the HTML (e.g. to use OOUI checkboxes).
Introduce new method getCheckboxesDefinition(), which
generates the checkboxes in a machine-readable format,
with a new hook 'EditPageGetCheckboxesDefinition'.
Rewrite getCheckboxes() in terms of that. The old hook
'EditPageBeforeEditChecks' is now deprecated.
Change-Id: I3dbe973dcac6cba0c3a1ac5d983cafcfb49d833c
Directly mention ChangesListBooleanFilterGroup and
ChangesListStringOptionsFilterGroup so people know what to construct.
Change-Id: I3c105d072889c1da26f94402326ba48635081833
Explicitly block two filters in the same group from having the same
name.
Before, it would be left to registerFilter, which would just cause
the second one to win.
Also, avoid a getFilter warning when the filter does not exist.
Do the same for getFilterGroup on ChangesListSpecialPage
Finally, a minor related doc fix.
Change-Id: I6b3880a5c7cc381c169bbd969cd4814559b49c91
This reverts commit 1525f6cd45.
This should be functionally equivilent to what was being done
before. When go is triggered but does not cause a redirect the
hook is called. Nothing is done with the result of the hook, same
as before.
Not going to bother deprecating, it doesn't particularly hurt the
architecture in any way, it was removed for being what appeared as dead
code due to a long removed feature. There are apparently a few usages of
this in extensions that may or may not work with recent releases of
mediawiki.
Bug: T160441
Change-Id: I368dec79431fbcc8d04f95afed8bbc7262a2e5de
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
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
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
Reasons:
* $text is vague. It's the label of the link. There is a function named
getTitleSnippet, which is what I'm reusing for the variable name.
* $page is vague. It's not the page of the search result, but the search
special page.
* $queryString is not a string but an array of strings.
I also updated https://www.mediawiki.org/wiki/Manual:Hooks/ShowSearchHitTitle
accordingly.
Change-Id: Ia18dbf5ccf7f9fcc8890ad01641d0b7ff3e6eee8
Changing hook signatures with no deprecation period is a no-no.
Fixes Ib527fc3a3c39eb2e56985e5d1e4905fc4562353c
Reverts I153a7d590faceb1e2c4fe7d95a5cb931cda0c301
Bug: T155625
Change-Id: I2b408691fc4435ef24fc62360bd7ad6114f385c7
In general, there's no reason to use by-ref on objects unless
the hook is supposed to replace them (this one isn't).
Change-Id: I153a7d590faceb1e2c4fe7d95a5cb931cda0c301
This was suggested at a Developer Summit session as a way to get people
to know about the mailing list.
This also adds a hook so ApiFeatureUsage can mention itself in
deprecation warnings too.
Bug: T148855
Change-Id: I04a7cf89e87e48f6504803dd173e779017a205d0
So that extensions like MessageCommons can try to use this (and
$wgLanguageCode) instead of $wgLang->getCode()/$wgContLang->getCode(), as
the latter ones cause fatals and recursion, at least with the Gadgets
extension also enabled at the same time.
Change-Id: If71fe1ded26c7a1c771128397783783ad5715b00
First step in refactoring the search results page. Pulls out widgets
to render our two styles of search result, Full and Simple.
Bug: T150390
Change-Id: If78cb0c29ae394f16e465c15a8e8246c1b56dcea
Currently, there is no hook that runs before a user's groups are changed. Adding a hook here will allow for action before the groups are changed.
Bug: T49338
Change-Id: I87dbb6a8eb897f4a40215d33d1a0b24af7efa871
Currently, there are two hooks ('BlockIP' and 'BlockIPComplete') that run when a user or IP is blocked in Special:Block, but no similar hooks when a user is unblocked in Special:Unblock. Adding these two hooks allows an extension to add and remove criteria about a user/IP unblock before it occurs and for possible action after an unblock is completed.
Bug: T50546
Change-Id: I9d9888dc5f1bb6a8bc62e90e6a423bf56b05173b
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
