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
The current API implementation has a parameter for uploads that is
called "ignorewarnings". Currently, it will not only suppress any
warnings from stopping the upload, it will also lose any data from
those warnings.
This patch is sort of on the way to solving Bug 30625, which is in
the UploadWizard extension. That extension needs to know when a file
upload *will* fail, barring a change in some data, in order to make
it easier for a user to fix the foreseeable problems. The solution is
either to fix it this way, or to somehow spoof a file upload, and see
if it succeeds. In the hopes that other extensions will also find
this useful, I opted for the former.
Change-Id: I08b4e29e89ade6cf391ae044fceb788aaba3f5b4
Chunked uploading is currently only implemented by Upload Wizard,
but is supported in MediaWiki core. It's enabled in Upload Wizard
by setting $wgUploadWizardConfig['enableChunked'] to true.
When enabled, large files will be split into smaller chunks, by
default of 1 MB. This is done through a series of API POST
requests. The file is identified by means of a 'filekey' to
allow for continuation of uploads from previous offsets.
Previously broken behavior: Files were concatenated correctly,
but instead of the whole file, one of the chunks was uploaded
to the wiki. This was due to the API using the filekey of the
chunk, as opposed to the filekey of the whole file.
In addition, this change also cleans out the stash information
for both filekeys after the upload is complete.
[Patch set 2: Whitespace fix]
[Patch set 3: Move filekey result past status check]
Change-Id: Idac94e953676787f9516051e47c006525f198fd4
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.
Implemented changes suggested in code review on r92009:
constructor bug handling passed repo/stash
up-to-date timestamp generation
fetching db handle from repo
iterating over select results according to convention
changed uploadstash.us_media_type to enum to mirror image.img_media_type
removed (most) new references to $wgUser, instead using ApiBase::createContext to find the user
