API continuation parameters encode sufficient state for a subsequent
query to continue where the previous one left off; this may sometimes
include page titles, with or without the namespace. Given that these
page titles are already in the exact format required for the next
request's SQL query, it is not necessary to "normalize" them in any way.
And if normalization does more than just change spaces to underscores or
vice versa (e.g. it canonicalizes namespace aliases or capitalizes the
first letter of the title), it can be actively harmful: see bug 36987
and bug 29290.
Note this patch involves a breaking API change: the values for the
"continue" parameter of various modules have been changed, and some
modules will now return "continue" as the continuation parameter instead
of reusing "from".
Note this patch also corrects a minor logic bug in ApiQueryAllLinks,
changing ">" to ">=". The line is being changed anyway, so I didn't
bother doing a separate changeset.
Change-Id: I459232e919d20f89f6de9d20640fd48c8fd5781c
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
Removed unused globals $wgHooks, $wgBlockAllowsUTEdit, $wgUser, $wgOut
$wgUser was already set global at function beginning.
Moved global out of switch
* Adds a condition fa_deleted=0 if the user does not have the suppressrevision rights. This field is unindexed. This should however not be a big problem as files with fa_deleted are rare. Unfortunately this hides files that do not have DELETED_RESTRICTED, but I don't know how bad fa_deleted & DELETED_RESTRICTED = 0 is for performance
* Added deletedfile, deletedcomment, deleteduser and deletedrestricted to the output for what I think are appropriate fa_deleted fields, but it's hard to tell what's corrent without a single line of documentation or even comment in the code. Perhaps somebody can dig up a commit message where the purpose of the constants is explained?
* Introduced a "cache mode" concept to simplify the header generation code, and to avoid odd results when conflicting cache header requests are received from submodules, or at least to formalise the handling of such cases.
* Made the cache mode private by default, so that code written in ignorance of caching tends to be safe. If different query modules are used in a single request, private caching is preferred over public caching.
* Removed the "must-revalidate" option from all CC headers, this is really specific to page views with a hacked squid in front, I don't think it's applicable here.
* Made the watchlist module private. This is really the definition of private data. There's nothing in the HTTP spec that says the URL for a CC:public request is private and can't be leaked. CC:private provides protection against unknown proxy behaviour.
* In ApiQueryAllmessages: avoid calling $wgLang->getCode() to check if it's necessary to make a new $wgLang when lang= is specified, since this is the only thing that unstubs $wgUser.
* Removed "FIXME: should this check $user instead of $wgUser?" Answer is no.
