Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Accidentally broken by I991809acf.
Also added a test that should hopefully prevent this from accidentally
being broken again.
Bug: T245149
Change-Id: Ia7985397db50efe8af81f643f2a0a89d0ece179e
This will allow constructing API modules that need services.
This overhauls some of the internals of the ApiModuleManager,
but the public interface remains unchanged.
The $class parameter of addModule, (now called $spec)
also allows passing an array with the spec of the module.
Note that this spec requires the attribute 'class' to be present,
even when 'factory' is specified. This is the same as before,
where $class was always required.
In a perfect DI world ObjectFactory would be injected into
ApiMain::__construct and ApiMain would pass that to its instance
of ApiModuleManager, but that is currently not possible, so for now
it is injected in ApiModuleManager by having ApiMain::__construct
call the service locator.
Bug: T222388
Change-Id: Iee04afc27283547dd68d6db93f44ac2e0ebf1258
This API module can be used to get information about all the languages
supported by this MediaWiki installation. Since parts of this
information, such as the fallback chain, are expensive to retrieve if
the localization cache is not populated, we apply continuation if the
request is taking too long (suggested by Anomie in T217239#4994301); we
don’t expect this to happen in Wikimedia production, though.
Bug: T74153
Bug: T220415
Change-Id: Ic66991cd85ed4439a47bfb1412dbe24c23bd9819
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces calls to
Title::userCan() with the new service in API classes.
Bug: T220191
Change-Id: I768d07a520ca6473a4eefb88c9f587657bc74357
I would argue that these comments do not add any information that
would not be there already. Having them adds mental overhead, because
one needs to read both the comment and the next line of code first to
understand they say the exact same. I don't find this helpful, but
more distracting.
Change-Id: I39c98f25225947ebffdcc2fd8f0243e7a6c070d7
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
If someone is both dumb enough to blindly save an API response and to
then execute the resulting file, this can be used to attack their
computer.
We can mitigate this by disallowing PATH_INFO in api.php URLs (because
we don't make any use of them anyway) and by setting a sensible filename
using a Content-Disposition header so the browser won't go guessing at
the filename based on what is in the URL.
Issue reported by: Abdullah Hussam
Bug: T128209
Change-Id: I8526f5cc506c551edb6138d68450b6acea065e93
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
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
For example file pages from foreign repos, MediaWiki-namespace messages
that haven't been locally customized, and titles manipulated with the
'TitleIsAlwaysKnown' hook.
This allows clients to be able to display such titles as bluelinks
rather than redlinks.
This also has ApiPageSet populate LinkCache to make later checks of
->exists() and ->isKnown() more efficient.
Bug: T141963
Change-Id: Idbdfd2896c0ce9425ededd7cb4b60eda89ba7ef5
Some generators (e.g. generator=recentchanges) in their default mode of
operation are particularly prone to not generating the same result set
on subsequent requests due to intervening activity on the wiki adding
new entries to the start of the list. We can mitigate this effect by
allowing such generators to provide "non-continuation" data to be used
if the generator isn't being continued.
ApiQueryRecentChanges and ApiQueryAllRevisions are updated to set this
new property. Other generators can easily be updated in the same way as
needed.
There isn't anything we can do about generators prone to having entries
added at random positions in the list rather than the beginning,
unfortunately.
Bug: T146176
Change-Id: I8308d6aa2c89fd2a85e74c7dd8a0a2a9ec927490
All deprecated ApiResult methods are removed. These have been deprecated
since 1.24 or 1.25, and the only users remaining in Gerrit are wrapped
in backwards-compatibility checks and so should not be being called.
ApiBase, ApiFormatBase, ApiMain, and ApiQuery methods for generating the
pre-Ib14c00df help text are removed. Nothing has called these for a long
time, and only Flow implemented them in any way. Deprecated methods for
providing the text for such help, such as getDescription(), haven't been
removed yet, though, since some extensions still call some of them.
Change-Id: I3ca7c98174b4a3f6f67f2b023e0f4446637e7a84
Though getOutput() is what first came to mind, I do not particularly
like the name, partly because it is used in many, many places as a
method that returns an OutputPage object.
* Renamed the method to __toString(). This is appropriate because
each instance, at any given time, corresponds to a single string
value (and exceptions cannot occur during this conversion).
* Removed unnecessary variables from ApiQuery and ExportTest. In
these and most other cases, it should no longer be necessary to
call getOutput() explicitly.
Change-Id: Icf202743d1f332f8981338f42eb6e3e5a04abdf1
Specifically, it is not necessary to use output buffering functions
to capture XML generated by the export code because it is already
possible to set the "output sink" object to be used.
* Created a DumpStringOutput class, which appends all output to a
string property rather than printing output immediately.
* Used that class, instead of ob_start() and ob_get_clean(), in
ApiQuery and ExportTest.
Change-Id: I238f5d5ec7fd442c845b25cb59ef81ac3285099f
* Set API response metadata on the AuthenticationRequest metadata so it
is output as an assoc generally.
* Remove the 'image' field in AuthenticationRequest::getFieldInfo()'s
response, since we ended up not using it anywhere.
* Make it so meta=authmanagerinfo can be used on private wikis without
logging in, so action=clientlogin can be used to log in.
** This generalizes the exception for meta=tokens that was added in
I83dafb030.
* ApiAuthManagerInfo needs the "messageformat" parameter.
* ApiAuthManagerInfo shouldn't be publically cached, since the responses
vary depending on session state.
Change-Id: Iea5ddb4ef9febed18f16a7ae8314968026f39148
Changes here are:
* action=login is deprecated for use other than bot passwords
* list=users will indicate if a missing user name is creatable.
* Added action=query&meta=authmanagerinfo
* Added action=clientlogin is to be used to log into the main account
* action=createaccount is changed in a non-BC manner
* Added action=linkaccount
* Added action=unlinkaccount
* Added action=changeauthenticationdata
* Added action=removeauthenticationdata
* Added action=resetpassword
Bug: T110276
Bug: T110747
Bug: T110751
Bug: T32788
Bug: T67857
Bug: T28597
Bug: T76103
Change-Id: I244fa9b1e0623247d6d9fa30990411c6df94a496
The problem is that ApiQuery requires the 'read' right even though
ApiQueryTokens doesn't.
So, we introduce an exception: if action=query gets only meta=tokens
(and optionally rawcontinue and indexpageids, since they don't affect
anything), no other modules and nothing in the ApiPageSet,
ApiQuery::isReadMode() will return false.
Bug: T130112
Change-Id: I83dafb0305ff0cb1fc3bac668b88b5d2022e5880
No more uses found in core or Gerrit extensions for the following methods:
* ApiQuery::getGenerators() was removed (deprecated since 1.21).
* ApiQuery::getModuleType() was removed (deprecated since 1.21).
* ApiQuery::setGeneratorContinue() was removed (deprecated since 1.24).
Change-Id: I1d46adc9ecad598c7d7726a2243bba4f7a04531a
Only works for the currently logged-in user (I'm not sure how that works
with bots, if OAuth will do that correctly or whatever) but will help us
do some neat stuff with tools that use the stash - including resuming
uploads.
Bug: T85561
Change-Id: I215ac6936185563f4c7b42a4bced65e4b096fd15
Re-adds I6f807adc9cbf71c5d7b83c7eec43965dce1d2a16 and
Ic04daf475b936b942833362c7a979dde671b3ef4 (reverted in
35ccd9c2fe) with 1:1000 sampling
to avoid swamping the statsd hosts.
Also fixes query module logging.
Bug: T102079
Bug: T106450
Change-Id: I8b9366407c0d1713790d08e69aaa518130f01977
The new format is much easier to use correctly, and should therefore be
the default. The old format is maintained for clients that need the
additional flexibility.
Bug: T96858
Change-Id: I984e63581f4ef23ccada916b6d45131d1fb5e001
While we could fix the issue at hand by moving the setArrayType() call,
it's more robust to explicitly remove *all* metadata.
Bug: T96942
Change-Id: I313b19339474ea34880ebef31851eefdf14a7a07
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
It's excessively difficult to determine if the logs of people hitting
this warning are really going to be affected by the change or if they're
making queries where it won't actually matter.
Since 1.26 is coming soon, and with it the decision as to whether to
pull the switch on I984e6358, let's retarget the warnings to those cases
where it's possible it would actually break someone's code.
Change-Id: I91f170fd7d4c791ca8f5d3592c888700f4d5aa97
The profileIn/profileOut pair should be covered by the Xhprof profiling
of the method calls it was wrapping.
The profileDBIn/profileDBOut pair are covered by profiling done by the
Database class.
Nothing in extensions in Gerrit is calling anything besides the
profileIn/profileOut pair (and likely those are only to avoid core
formerly throwing exceptions from internal profileDBIn/profileDBOut
calls), and nothing in core or extensions-in-Gerrit is using the methods
for fetching profiling data.
The methods are left as stubs for now to allow for backwards
compatibility in extensions.
Change-Id: I05ba4e2762dc86d5e2bafc183dce701239b43f5c
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
It has long been requested that list=search and list=prefixsearch be
able to indicate the search result ordering when used as generators.
This change introduces a generic mechanism to allow for generators to
specify additional page data.
Bug: T16859
Bug: T75623
Change-Id: I115338d2bd890ccc109a79c65f92099c0d41fc2d
