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
