The API action=upload returns a generic error message when one or more
of the file extensions are blacklisted. It should return a more
informative message, and also return the list of blacklisted extensions
in a machine-readable format.
This changeset introduces a new message,
"api-error-filetype-banned-type", which is to
"api-error-filetype-banned" what "filetype-banned-type" is to
"filetype-banned". As a starting point, I've copied (with minor changes)
the existing filetype-banned-type message to
api-error-filetype-banned-type for all languages for which both
api-error-filetype-banned and filetype-banned-type are currently given.
This changeset also incidentally fixes an internal server error with
format=xml when the filetype-banned error is returned by the API.
Change-Id: I6b0c58fbc5b19aa55286c56fa7da2195ea683ae0
action=block/action=unblock can not have the token required because when
using the gettoken param, the token param can not set.
Change-Id: I15317f16c06f150d29c1b17de76f41a6cfa84820
The API currently doesn't return any indication of the warnings on
a successful upload where the API call had ignorewarnings=true.
This patch allows the client to handle the warnings gracefully.
Patchset 2: Document it properly.
Patchset 3 and 4: Rebase.
Patchset 5: Document it even more properly.
Patchset 6: I didn't understand doxygen properly.
Change-Id: I09c8f3dc13832df55a0ffa9e8b9380aaa4038cf1
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
