Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
While redirects can be sort-of queried using list=backlinks with
blfilterredir=redirects, we can get more accurate results with a module
dedicated to this purpose. We can also get the fragment of the redirect
without having to load the content of the redirect page and parse it.
I'm a bit surprised I was able to put together a query for this that
will work as a prop module. Or did I overlook something?
And then we may as well add the corresponding list=allredirects, to work
like alllinks, allfileusages, and alltransclusions.
Bug: 57057
Change-Id: I81082aa9e4e3a3b2c66cc4f9970a97eed83a6a4f